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

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

1. ### Andrew Watt [MVP]Guest

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. Then$Fred = 1

and then

get-history

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?

Thanks

Andrew Watt MVP

Andrew Watt [MVP], May 12, 2006

2. ### Andrew Watt [MVP]Guest

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: then$Fred3 returns variable:

and

$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
global?

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

3. ### Wei Wu [MSFT]Guest

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. ### dreeschkindGuest

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. -- greetings dreeschkind dreeschkind, May 13, 2006 5. ### Alex K. Angelopoulos [MVP]Guest 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. ### Andrew Watt [MVP]Guest Satish, Thanks for the reply. Can you explain why that approach was chosen? Thanks Andrew Watt MVP Andrew Watt [MVP], May 15, 2006 7. ### dreeschkindGuest Uhh, somebody likes my idea 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 131 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 dayly. 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\ ... variable:\foo\bar\... Or as I suggested, putting variables in different containers, according to their scope:$global\myGlobalVariable
$private\myPrivateVariable$script\myScriptVariable

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
convenient.

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

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
directory.
So finding a particular cmdlet would just be a piece of cake.

cmdlet:\PSCore\get-item
cmdlet:\PSCore\rename-item
....
cmdlet:\3rdParty\doo-foo

cmdlet:\audio\convert-audiofile
cmdlet:\audio\play-audiofile

cmdlet:\image\show-image
cmdlet:\image\convert-image
cmdlet:\image\print-image

Or imagine something more general like this:

commands:\cmdlet\...
commands:\cmdlet\PSCore\...
commands:\scripts\...
commands:\function\...
commands:\filter\...
commands:\application\exe\ (apps that are in the path are sorted into
containers)
commands:\application\com\ (invoking this is like a link to the real app)
commands:\application\bat\
commands:\application\vbs\

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
filesystem.

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?

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
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