Here's the command line and the output:

PS>echo "a"bc d"e"f gh"i"
a
bc
def
ghi



Why is the first token seperated into two pieces while the other two stay in
one piece? [By the way, it's the same with single quotes, as well.]

This parsing makes the idiom of using tab-expansion with automatic quoting
more difficult to use. Adding text (including wildcards) onto an expanded
path with internal spaces (and therefore automatically quoted) does not give
the usually intended result. Instead, the user has to delete the last quote,
add the text, and the re-add the last quote (or back into the string to add
the extra text). For example: "C:\Documents and Settings"\a* parses into two
seperate command line tokens ("C:\Documents and Settings", "\a*") not the
single token ("C:\Documents and Settings\a*") as most shell users would
expect.

Is this purposeful? If so, what problem does it solve? If not, it should be
changed to a more consistent and intuitive parse.

All three should intuitively parse to similar tokens, either split at the
quotes or combined, each as a single token. Alternatively, they should all be
split similarly at the quotation marks (although that would be the wrong
result IMHO, it would at least be consistent).

Thoughts?

- Roy Ivy

The 'problem' stems from PowerShell not always requiring you to quote
strings.
In all cases, properly quoting them and not taking such shortcuts
resolves the issue.

PowerShell lets you get away with not using explicit quotes by
assuming that any sequence of characters in an argument that doesn't
start with - (dash) is a string object. It uses space as an implicit
delimiter to the end of the string. Sequences starting with - are
param names (except after the special param --)

"a" is already a quoted string
next comes bc which it converts to a string which is delimited by the
space after 'c'.

In the next 2 sequences the behavior you see is the logical outcome of
implicit variable concatenation.

PS> function a ([string]$s){"'$s'"}
PS> $a = 'abc'
PS> $b = 'efg'
PS> a $a $b
'abc'
PS> a $a$b
'abcefg'
PS> a $a$b.c
'abcefg.c'
PS> a $a"wxy"$b.c
'abcwxyefg.c'

I'm pretty sure the way this works was carefully planned and that it
is actually working as planned.
So there is nothing to 'fix'.
It's easy to see why you might be initially confused though.

Roy Ivy III wrote:

> Here's the command line and the output:
>
> PS>echo "a"bc d"e"f gh"i"
> a
> bc
> def
> ghi
>
> Why is the first token seperated into two pieces while the other two stay in
> one piece? [By the way, it's the same with single quotes, as well.]
>
> This parsing makes the idiom of using tab-expansion with automatic quoting
> more difficult to use. Adding text (including wildcards) onto an expanded
> path with internal spaces (and therefore automatically quoted) does not give
> the usually intended result. Instead, the user has to delete the last quote,
> add the text, and the re-add the last quote (or back into the string to add
> the extra text). For example: "C:\Documents and Settings"\a* parses into two
> seperate command line tokens ("C:\Documents and Settings", "\a*") not the
> single token ("C:\Documents and Settings\a*") as most shell users would
> expect.
>
> Is this purposeful? If so, what problem does it solve? If not, it should be
> changed to a more consistent and intuitive parse.
>
> All three should intuitively parse to similar tokens, either split at the
> quotes or combined, each as a single token. Alternatively, they should all be
> split similarly at the quotation marks (although that would be the wrong
> result IMHO, it would at least be consistent).
>
> Thoughts?
>
> - Roy Ivy

Rick,

Thanks for the answer. I appreciate the effort to define the problem, but
your answer doesn't get at the basic issue of my question.

I'm not confused about the process of "implicit variable concatenation", but
why it applies to a"b" and not to "a"b. It seems surprising and like an
inconsistency to me. If it's necessitated by some parsing rule and can't be
changed, so be it. But I'd like to know why. If it's not specifically
intended, I wonder if it can be changed to be less surprising.

The current implementation gets in the way of common tab-completion usage.
Most tab-completion implementations automatically surround expanded paths
with quotes. Adding additional text, such as wildcards, to the completion
gets separated into two tokens unless the additional text is placed _inside_
the trailing quote, which is not the usual practice. Trivial maybe, and
fixable if tab-completions start using backticks to quote the internal
whitespace, but a common occurance.

Not a big deal, but IMO the principle of least surprise, especially for a
new product such as this, is worth the pursuit.

- Roy

"RickB" wrote:

> The 'problem' stems from PowerShell not always requiring you to quote
> strings.
> In all cases, properly quoting them and not taking such shortcuts
> resolves the issue.
>
> PowerShell lets you get away with not using explicit quotes by
> assuming that any sequence of characters in an argument that doesn't
> start with - (dash) is a string object. It uses space as an implicit
> delimiter to the end of the string. Sequences starting with - are
> param names (except after the special param --)
>
> "a" is already a quoted string
> next comes bc which it converts to a string which is delimited by the
> space after 'c'.
>
> In the next 2 sequences the behavior you see is the logical outcome of
> implicit variable concatenation.
>
> PS> function a ([string]$s){"'$s'"}
> PS> $a = 'abc'
> PS> $b = 'efg'
> PS> a $a $b
> 'abc'
> PS> a $a$b
> 'abcefg'
> PS> a $a$b.c
> 'abcefg.c'
> PS> a $a"wxy"$b.c
> 'abcwxyefg.c'
>
> I'm pretty sure the way this works was carefully planned and that it
> is actually working as planned.
> So there is nothing to 'fix'.
> It's easy to see why you might be initially confused though.
>
> Roy Ivy III wrote:

> > Here's the command line and the output:
> >
> > PS>echo "a"bc d"e"f gh"i"
> > a
> > bc
> > def
> > ghi
> >
> > Why is the first token seperated into two pieces while the other two stay in
> > one piece? [By the way, it's the same with single quotes, as well.]
> >
> > This parsing makes the idiom of using tab-expansion with automatic quoting
> > more difficult to use. Adding text (including wildcards) onto an expanded
> > path with internal spaces (and therefore automatically quoted) does not give
> > the usually intended result. Instead, the user has to delete the last quote,
> > add the text, and the re-add the last quote (or back into the string to add
> > the extra text). For example: "C:\Documents and Settings"\a* parses into two
> > seperate command line tokens ("C:\Documents and Settings", "\a*") not the
> > single token ("C:\Documents and Settings\a*") as most shell users would
> > expect.
> >
> > Is this purposeful? If so, what problem does it solve? If not, it should be
> > changed to a more consistent and intuitive parse.
> >
> > All three should intuitively parse to similar tokens, either split at the
> > quotes or combined, each as a single token. Alternatively, they should all be
> > split similarly at the quotation marks (although that would be the wrong
> > result IMHO, it would at least be consistent).
> >
> > Thoughts?
> >
> > - Roy Ivy

>