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=cne
> $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
> |