Vista - Argument that starts with '-' and contains ':' gets separated.

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

Just because .

Actually, it's probably the space (or lack thereof) having more of an
effect. PowerShell treats spaces as delimiters; it's not so much a "-" that
it looks for to begin an argument name, but rather " -" (that is, a space
and a dash). It looks for the next space to seperate the argument name and
value. The colon is obviously another character it "looks" for - I don't
think it wants to see them in argument names, and in your last example it
would "think" that the colon was part of the argument name (no spaces) so
"broke" it there.

--
Don Jones
Windows PowerShell MVP
Founder: www.ScriptingAnswers.com
Co-Author: "Windows PowerShell: TFM"

"Dan" <dz.open@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
>

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 -namene -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.open@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
|

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

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