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

[Linda Walsh]

Greg Wooledge wrote:
> I prefer plan C: leave it alone.  It's working fine.
----
        Your preference could be used as an excuse to stop
all future growth in primitive interfaces, however 'fine'
is in the eye of the beholder.  If everything was fine with
the shell, we'd all be using borne shell, and not the
very much improved 'bash' shell (even if it has inherited
bourne's quirks).  

        So you are saying that you would prefer a non
functional error to a functional feature as you believe that
non-functional errors are 'fine'?

        How does that work for you in your professional
life?  ;^)

        Just because something is 'fine' for you doesn't mean
that other things wouldn't be 'just as fine' (for you), yet be
more flexible, work better or be more fine for others.

        Despite shades of vitriol surrounding this topic, I don't
understand why it wouldn't be preferable to allow greater functionality
where it provides no backwards incompatibility.  Such has been the
case with other operators implemented in Bash.

        Running into another 'bash' error today, I'm reminded of a
bad philosophy that software has tended toward in the past 10-15 years, 
that I would strongly urge people to think about in their implementations
and try to avoid -- and that is 'giving up and dying at the first 
misplaced "anything", rather than trying to understand what the user 
might have meant in cases where making a guess about what the user meant 
would be *very* unlikely to cause harm.

        Case in point was in a cron job -- I forgot a closing quote
on a command, something like:

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

where a single quote was missing at the end of the line.  What would
be the downside of presuming to terminate any open string at the end of
the whole string, rather than dying with a missing "'" error?

Certainly there are situations more complicated than the above where
such help would NOT be helpful =-- like if there were multiple sets
of quotes: which set of quotes wasn't balanced -- can't really tell, in that
case, better to die.  But in the case of 1 missing quote?  Though, realistically, I'd still be likely to throw out a warning.  

Alternatively, I might have a flag to pass to bash (or a 'shopt' option' to
be relaxed about syntax/semantic errors where there was a  low possibility
of ambiguity, and not issue error messages, were if that option wasn't
enabled, then it would just do that suspected correction and continue w/o
warning or error.

The very first compiler I used as a student in a CS course has a remarkably
intelligent error recovery feature -- and was right 80-90% of the time in
repairing simple syntax errors in a program so that it could continue to
parse the program and attempt an execution.  Of course this was when 
programs were submitted as 'batch' jobs via 'cards', and making a correction
and an additional run might cost you 30+ minutes of wait time during 
heaving mainframe usage!

But things like missing semi-colons at end of lines, or unbalanced quotes
on a line, or variables not properly declared...etc.  It was good about
patching up erroneous code and rarely got it wrong.  Of course it still 
spit out a bunch of warnings about bad syntax, and the fixups it made, 
but having it try to make sense out of common mistakes seemed so much
more user-friendly, than being completely 'dumb' and dying at the first
trivial syntax error.


In the same way -- in this circumstance, I'm suggestion to make 
legal 'sense' out of multi-word arguments to either side of a match
operator where such arguments would otherwise generate a syntax 
error -- and, instead, treat those multi-word arguments as
grouped-terms -- just as multi-word arguments inside unquoted
variables are _magically_ treated with these new operators.

So far, no one has come up with any good reasons why this would be a 
problem, or how it would create any compatibility problems.  All I've
seen is an attitude of 'well, I don't wanna!  It's my toy and I didn't
think of the idea, and well, you're just weird anyway..."...  or some
such 'reasoning'...  of course I could be making invalid assumptions,
but, hopefully, as has already been shown in the course of this
discussion, if I DO make invalid assumptions, once I understand the fault,
I'm willing to acknowledge it and move forward to a different solution
that can still work for all parties involved.  I _try_ for solutions
that work for the various parties involved.

I continue to move forward in trying to understand pragmatic and or logical
objections and remove roadblocks.  I think I've made a fair effort at
doing that here as I've yet to hear any compatibility problems, or why things
couldn't or shouldn't work in one (or both) of the ways I propose.  I'm
not sure why there is such resistance to making non-harmful
improvements (?)...

Linda