How would it know what your intent is? As far as psh is concerned, your in
the psh business. What you start after that is your business. They could
probably add some other switch, to not do any parsing or not parse if there
is no matching parm name (which would seem reasonable here), but that starts
getting into one offs - and one-offs get very complex fast and start
weighing down the whole product. Like you said, the workaround is pretty
simple and explicit.
--
William Stacey [C# MVP]
"DZ" <noah.boy@gmail.com> wrote in message
news:1179171654.654985.150950@l77g2000hsb.googlegroups.com...
|
| Thanks, I understand now.
|
| Though, I must say that I find this behavior a little annoying if you
| must invoke non-powershell scripts or executables, especially if you
| are used to other command line interfaces. I spent quite a bit of time
| trying to figure out why my command wasn't working properly.
|
| It would be nice if PS could somehow parse the arguments differently
| depending on what the target of the arguments are. For example, if you
| are not invoking a cmdlet or PS script, the parse the command line in
| the "conventional" way.
|
| Dan
|
|
| On May 13, 6:55 pm, "William Stacey [C# MVP]"
| <william.sta...@gmail.com> wrote:
| > In psh, you can use a space or a colon to seperate the parm name from
the
| > value of the parm:
| >
| > # Use a space or a colon
| > mycmd -name
ne -name2:$var1 -name3 $var2
| >
| > So in your last example your parm name is everything upto the colon
| > (i.e. -hello=c
and the value is everything after the colon upto the
first
| > space. So in terms of a psh script, this is expected behavior.
| > If you have a Param that matches the parm name on the cmd line, that
param
| > will be set with the value.
| >
| > # parms.ps1 test script
| > #
| > param(${hello=c}) # We have the use the ${} syntax to hide the "="
| > '$hello=c value: ' + ${hello=c}
| > "Args value: $args" # everything left over not pluged into a param
| >
| > Test
| > ---------
| > PS C:\> .\parms.ps1 one two three
| > $hello=c value: one
| > Args value: two three
| >
| > PS C:\> .\parms.ps1 two -hello=c
ne
| > $hello=c value: one
| > Args value: two
| >
| > Note in both cmd line example the var $hello=c is set to one. The first
| > case is because "one" is Position 1. In the second example, the var is
set
| > to one because it *matches the Param name of "hello=c".
| >
| > --
| > William Stacey [C# MVP]
| >
| > "Dan" <dz.o...@gmail.com> wrote in message
| >
| > news:1178921284.945251.87840@u30g2000hsc.googlegroups.com...
| > |I discovered that when I execute a program from the PS command line
| > | and I try to pass an argument that starts with a hyphen (-) and
| > | contains a colon (
, the argument will be split into 2 arguments at
| > | the colon.
| > |
| > | To demonstrate, I wrote a simple python script then merely echoes out
| > | all the arguments in argv:
| > |
| > | PS C:\3rdParty> .\testPSArgs.py c:\goodbye
| > | arg: C:\3rdParty\testPSArgs.py
| > | arg: c:\goodbye
| > | PS C:\3rdParty> .\testPSArgs.py =c:\goodbye
| > | arg: C:\3rdParty\testPSArgs.py
| > | arg: =c:\goodbye
| > | PS C:\3rdParty> .\testPSArgs.py hello=c:\goodbye
| > | arg: C:\3rdParty\testPSArgs.py
| > | arg: hello=c:\goodbye
| > | PS C:\3rdParty> .\testPSArgs.py -hello=c:\goodbye
| > | arg: C:\3rdParty\testPSArgs.py
| > | arg: -hello=c:
| > | arg: \goodbye
| > |
| > | Now, of course, the workaround is fairly simple, merely enclose the
| > | argument in quotes:
| > | PS C:\3rdParty> .\testPSArgs.py "-hello=c:\goodbye"
| > | arg: C:\3rdParty\testPSArgs.py
| > | arg: -hello=c:\goodbye
| > |
| > | I was just wondering, why does it parse the command line in this way?
| > |
| > | thanks,
| > | Dan
| > |
|
|