[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RFE: request for grouping mechanism to work in double brackets where

From: Linda Walsh
Subject: Re: RFE: request for grouping mechanism to work in double brackets where otherewise illegal
Date: Thu, 23 Sep 2010 15:08:36 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Thunderbird/ Mnenhy/

Pierre Gaston wrote:
I though I showed you how your suggestion only solves part of the problem
in only one particular situation and in an inconsistent manner while
other problems but oh well
        What are you referring to?  I thought I answered
your questions.

You questions:
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
        My answer was that any expression that would currently have
a legal interpretation would be interpreted the same as it is now.
So you expression would be interpreted as it currently is.  However,
if you wrote

[[ foo =~ this bar && baz ]]  ==> then

[[ foo =~ this ( bar & baz ) ]] --? legal under current rules?  => no.
[[ foo =~ (this bar && baz ) ]] -- legal interpretation under current rules?  =>
If we make =~ have 'grouping' precedence as I've suggested, the the only
possible interpretation would be
[[ (foo =~ this bar ) && baz ]]...

Have I answered this question yet?

---- (My original answer was to use parenthesis to disambiguate ambiguous
cases, if you want something other than the new default interpretation)
If you *really* want to match a pattern with "&& baz" being part of the pattern,
[[ foo =~ this bar \&\& baz ]]  -- that would use the entire right side
as a matching expression (as well as)
[[ foo =~ this bar '&&' baz ]]

Then you asked.
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?
I answered you -- didn't you see this?
   "You'd be no worse off than you are now -- you'd have to use backslash
or some other quoting mechanism."
These were the specific examples you gave needing to be addressed.

You also said:

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.

Which sounded more like commentary than a specific problem.
Of course you would have to quote *operators* like && and || -- if you wanted 
to stop them from functioning as operators.  But that's true in expressions elsewhere.  
I can't say


and expect a to have 'b&&c' in it if I don't quote the operators. So in that respect, it's completely consistent with other areas in the shell.

AS for suggestions that I implement the code -- if I thought that was the only 
thing keeping it from going into the next version of bash, I'd make it my next 
project (no promises on how long it would take me with my flakiness, BUT, if 
you are saying that's the only roadblock....

As for:

Dennis Williamson wrote:
OK, my magic error corrector chose this as its output:

bash -c 'cd foobar' && ci <options> filename

Is that what you were hoping for?
In the case of a missing quote, I think I suggested that the end of
the string close current quotes, so closing the quote in the middle
of the string wouldn't be expected behavior, but more...

  bash -c 'cd foobar && ci <options> filename<End-of-string> =>
  bash -c 'cd foobar && ci <options> filename'
( && warning: closing quote assumed @ end of string)...

It's a simple case. If it's a complex case where there is more ambiguity, like:

  bash -c 'cd foobar" && ci <options> filename

There -- did they mean to use ' instead of " or what?  Dunno -> fail.


  bash -c 'cd "foo bar" && ci <options> filename<EOS> =>

would terminate it at then end with a single quote (and a warning)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]