Inconsistency about parsing Mandatory Parameters

Yesterday, I came across what I thought was a bug in PowerShell. Consider the following function:

Function Demo {            
This seems quite basic. It simply returns the argument that you enter for size.

75 >  demo 5

Now if you don’t provide a value you will get a prompt,and in ISE it will prompt like this


and you get the following output

77 >  demo

Simple stuff so far. But now, check this out. PS has some built in shortcuts for KB,MB,GB, and TB

79 >  1mb

So now we can do Demo 20MB and get the following

82 >  Demo 20MB

However, if we just run Demo with no parameters and get prompted as before, we get an error if we enter 20MB

83 >  demo
Demo : Cannot process argument transformation on parameter 'size'. Cannot convert value "20MB" to type "System.Int64".

The PowerShell Team closed my bug on this and marked it “By Design.” The reasoning is around security with the following explanation:

“The prompting mechanism is inherently insecure and we do not want to introduce a code execution bug similar to the mailer bug in the old ATT UnixPC. If the user is running an application elevated which uses script and an error results in a prompt, the user's ability to exploit that prompt should be as restricted as possible.”

That is fine, but my issue is that this provides an inconsistent user experience. I would think that typing a parameter argument or entering one from an input box should provide the same result. Maybe both should error out.

Comments (1) -

I actually wish the MB, GB, and TB shortcuts weren't there at all.  They don't really fit in with any of the other rules, and stand out as an exception.

To me it would have made more sense to just have standard variables called $MB, $GB, and $TB and we could just multiply, and then we wouldn't have that weird (though convenient) notation.

Comments are closed