Re: RFE: request for grouping mechanism to work in double brackets where otherewise illegal
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 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
Re: RFE: request for grouping mechanism to work in double brackets where otherewise illegal
OK, my magic error corrector chose this as its output: bash -c 'cd foobar' && ci 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 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 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 atti
Re: RFE: request for grouping mechanism to work in double brackets where otherewise illegal
On Thu, Sep 23, 2010 at 3:20 AM, Linda Walsh wrote: > > > 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 though I showed you how your suggestion only solves part of the problem in only one particular situation and in an inconsistent manner while introducing other problems but oh well
