bug-bash
[Top][All Lists]
Advanced

[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: Dennis Williamson
Subject: Re: RFE: request for grouping mechanism to work in double brackets where otherewise illegal
Date: Wed, 22 Sep 2010 20:27:41 -0500

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

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

Is that what you were hoping for?

There's a big difference between a compiler and an interpreter. The
former can afford to take the time to do some of the kinds of things
that you describe. Those same things would slow an interpreter down
too much.

By the way, I'm sure you're welcome to submit code to implement your
ideas. Working code is a little more likely to be accepted than what
if ideas. Keep in mind, though, that there's a tremendous burden of
compatibility, standards compliance and stability that gets carried on
the backs of maintainers of software like Bash. Not to mention the
tradeoffs that have to be made, in code, in design, in personal time.
Keep in mind that these people are also volunteers. They deserve more
gratitude than grief.

On Wed, Sep 22, 2010 at 7:20 PM, Linda Walsh <bash@tlinx.org> wrote:
>
>
> 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
>
>
>
>
>



reply via email to

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