Re: RFE: request for quotes as grouping operators to work in brackets as elsewhere.

[Pierre Gaston]

On Mon, Sep 20, 2010 at 10:28 PM, Linda Walsh <bash@tlinx.org> wrote:
>
>
> Pierre Gaston wrote:
>
>> Just quote the spaces and not the special chars:
>
> Pierre, your suggestion doesn't help clean up strings used inside of double
> brackets.  I wanted to avoid the need for multiple backslashes in an
> expression as it makes the expression less readable and more error prone.

Multiple backslash? I gave only one example with one backslash and gave several
without one, and even a solution where the regexp is inside quotes
like you initially
requested.

>> Note that the same problem and solution exist when you use filename
>> generation:
>>
>> for f in /some path/ withspaces/*; do  # doesn't work the path contains
>> spaces
>
> ----
>        I'm aware of that, but since [[ and ]] are new, and =~ is new, there
> is no legal interpretation for multiple arguments on either side of the =~
> operator.
>
> Since =~ permits comparing variables _without_ putting quotes around them,
> (as would normally be the case if you used the single square brackets and
> plain '='), why not extend that idea to not needing quotes between
> the =~ and either side of the double square brackets so literal strings
> benefit from not needing quotes as well.
> Of course, if quotes *are* included on the rhs, then the pattern matchings
> (glob or regex) would be disabled as happens now.
>
> Is there a downside to this syntax or this idea?
>
>
Besides introducing yet another parsing exception, while the actual
problem and solution probably exist
for as long as the bourne shell exist (and maybe before), what about:

[[ foo =~ bar && baz ]]

Should bar && baz be considered as one regexp? if not, how would you
write a regexp matching
`foo && baz' ? or `foo && baz.*' ? if yes how would you do and and
with a regexp?

What if you want to match `  bar && baz   ' with trailing or leading spaces?
Should you be able to also use space without quotes in this case and have
[[ foo =~ bar ]] and [[ foo =~   bar   ]] have different meanings?

Space are used to separates arguments everywhere in the shell and yes
quotes are sometimes
ugly and often causes trouble until you take the time to learn to use
them, but it's the price to
pay to avoid putting quotes around every argument every time you use
the command line interactively.

I don't see how your suggestion would help in the end since you would
still need to quotes some chars like && or || and the handling of
space would not be consistent with the rest of the shell.