[PS] Undesirable/dangerous behaviour with rename-item?

Discussion in 'Scripting' started by Andrew Watt [MVP], May 12, 2006.

  1. Try this:

    rename-item variable:\MaximumHistoryCount Fred

    The $MaximumHistoryCount variable is renamed to $Fred.

    Then try

    $Fred = 0

    and PowerShell complains that you can't set it to 0.


    $Fred = 1

    and then


    and you get multiple entries in the history.

    So the system seems not to protect $MaximumHistoryCount from renaming
    but does protect (the renamed) $Fred from being set to 0.

    Can others repro this?


    Andrew Watt MVP
    Andrew Watt [MVP], May 12, 2006
    1. Advertisements

  2. It seems there are several others - when all the following ran
    successfully I thought I would stop.

    With the prompt in variable:\

    rename-item DebugPreference Fred1
    rename-item Profile Fred2
    rename-item PWD Fred3

    all seemed to allow renaming of the relevant variables.

    This seems to me to be highly undesirable.

    But there are other wrinkles:

    In variable:\

    $Fred 3 returns variable:\

    but if you

    cd c:


    $Fred3 returns variable:


    $PWD returns the current directory

    I realise this is a scoping of variables effect (at least I assume so)
    but aren't variables such as $MaximumHistoryCount supposed to be

    Allowing renaming of such variables seems to me to be undesirable.

    I think I better go to bed before I find any more "wacky edge cases".

    Andrew Watt MVP
    Andrew Watt [MVP], May 12, 2006
    1. Advertisements

  3. If you rename MaximumHistoryCount to something else, the powershell engine
    will use 64 as the default value.

    Wei Wu [MSFT]
    Windows PowerShell Team
    Microsoft Corporation
    This posting is provided "AS IS" with no warranties, and confers no rights.
    Wei Wu [MSFT], May 13, 2006
  4. Andrew Watt [MVP]

    dreeschkind Guest

    I agree with Andrew that PowerShell's automatic variables should be protected
    from renaming just like the core functions are.

    Furthermore, I think it would make sense to prefix these variables (Error,
    DebugPreference, MaximumHistoryCount, ...) with "PS" just like PSObject,
    PSDrive, etc. This makes it easier to filter them out when browsing the
    Variable: drive.
    Of course $_, $?, $^ etc. should not have the PS prefix for obvious reasons.

    I was also thinking whether the scoping of variables could correspond to
    containers/directories in the Variable: drive. I think flat providers don't
    take advantage of PowerShell's possibilities.


    dreeschkind, May 13, 2006
  5. That's an intriguing idea. Could you feature it, and rough out some
    behaviors you were thinking of?
    Alex K. Angelopoulos [MVP], May 14, 2006
  6. Satish,

    Thanks for the reply.

    Can you explain why that approach was chosen?


    Andrew Watt MVP
    Andrew Watt [MVP], May 15, 2006
  7. Andrew Watt [MVP]

    dreeschkind Guest

    Uhh, somebody likes my idea :D
    Ok, I'm trying to explain some of my thoughts.
    (Sorry for my bad english).

    I like the concept of hierarchical data stores (providers/drives) in Monad.
    Then I realized that some of the drives are not hierarchical, but 'flat'.
    First, I was not sure whether hierarchical variable or function drives realy
    make sense, but after all, this is what providers/drives are for!
    As I see it, PSDrives are just different root containers for a hierarchical
    data store (PSProvider).

    So why do we need special 'flat providers' at all? Where is the consistency?
    Every drive shoud be a hierarchical data store, just like filesystem, cert
    and the registry!

    One example:
    PoSh 1 C:\>(gci function:).count

    I have 131 custom functions created on startup and I think this list will
    get longer and longer, especially on an admin box, where PowerShell is used
    Do you remember the times when filesystems had no directory and you had all
    your files in the root drive? That sucked.
    I like to have a clean environment, with everything put in hierarchical order.

    I also have some global variables defined that I often use, but when I do a
    get-childitem in variable: drive I see approx. 70 variables. And I can't find
    my special variables between all the PowerShell automatic variables.
    I already suggested putting a PS prefix on all of PowerShell's own
    variables, to find everything faster, but as you see, a hierarchical data
    store is much more powerfull.

    For the variable:\ drive I think of custom containers like this:

    $myprivatevariable\MaximumFunctionCount # my own variable
    $ps\MaximumFunctionCount # powershell variable

    just use containers and put the variable items inside:

    variable:\myprivatevariable\ ...
    variable:\ps\ ...

    Or as I suggested, putting variables in different containers, according to
    their scope:


    I know that the official syntax is like:
    $global:home = "c:\user\home"
    but I think using directories like in the filesystem might be much more

    Do custom named variable scopes make sense?
    You could have different variables with the same name, beeing in different

    Sometimes I can't see the idea behind what is a drive and what not and why
    is it like that.

    I think if you >waste< a drive just for 'flat data' like variable, alias,
    function, env, then you could as well have drives for flat date like
    processes or history:
    (I leave it to you which one might make more sense)

    Some examples:

    cmdlet drive
    ------ -------
    get-process process:\ (missing) # not hierarchical
    get-history history:\ (missing) # not hierarchical
    get-help help:\ (missing) # hierarchical
    get-command cmdlet:\ (missing) # hierarchical
    get-pssnapin snapin:\ (missing) # hierarchical ???

    get-alias alias:\ #
    hierarchical ???
    get-variable variable:\ #
    hierarchical ???
    get-function (missing) function:\ # hierarchical ???
    get-psdrive psdrive:\ (missing) # ???

    get-eventlog eventlog:\ (missing) # hierarchical
    get-env (missing) env:\ # ???

    Think about a cmdlet provider, with a cmdlet:\ drive that contains all your
    available cmdlets. Each snapin installs it's new cmdlets in it's snapin
    So finding a particular cmdlet would just be a piece of cake.




    Or imagine something more general like this:

    commands:\application\exe\ (apps that are in the path are sorted into
    commands:\application\com\ (invoking this is like a link to the real app)

    I have even seen things like a SnapIn provider before, but I think it has
    been dropped from the program and will not be included in V1. This would be a
    good place to install, manage and remove all your SnapIns and should be part
    of V1 if you ask me. I'm sure that ISV will start to mess up everything when
    there is no easy builtin mechanism to control it.

    Maybe some people do not like to organize functions and variables, but with
    an general hierarchical data store approach every body could decide to put
    his stuff in the root container or to put it in a subcontainer like on the

    I'm not an architect of PowerShell and I'm not sure if all my suggestion
    could work well the way that I suggested.
    I see problems with determining which item to use, when there a different
    ones with the same name in different containers. But this could be handled
    similar like in the filesystem. There might probably be some more problems
    with it and I have not thought about every aspect here, but as I said I think
    flat providers don't take advantage of PowerShell's possibilities.
    Things like clashing cmdlet, function or variable names can be avoided with
    proper item path and hierarchical cmdlet, function and variable drives.

    As I said at the beginning realy like the general concept of providers and
    drives for all types of different data stores, like registry and certificates.
    Wouldn't it be cool to browse the builtin Help just like a drive, too?

    Think about:

    Doing a get-childitem help:\ would give you the (sub)chapters with a short
    description. The Help is hierarchical (XML) anyway. There would be no need
    for scrolling endless paged textfiles like in *NIX. Just browse the help like
    a manual with chapters!

    Someone of the team mentioned in an earlier thread, that they are planning a
    special provider for 'lifecylce items' like sceduled jobs, system services,
    background tasks and stuff. So you could just create a new item in the jobs:\
    drive to create jobs. Or you could pause or restart background services.

    I know that "shipping is a feature, too". But I know that Microsoft admitted
    that it has a long history with bad design decisions (registry, explorer
    shell extensions, ...).
    I hope that this time, they spend more time on designing a consistent/clean
    system, because later on, you can't change and improve everything so easy
    because you have to be compatible with V1.

    Don't get me wrong I love PowerShell and it goes in the right direction, but
    to be honest, when I first read about Monad I hoped to finally get a more
    consistent/clean shell environment than I can see now in RC1.

    Please provide feedback on problems you see with this approach or on things
    that you would like to see implemented, too.
    I will then do a feature request on that.
    dreeschkind, May 16, 2006
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.