Re: why does errexit exist in its current utterly useless form?
On Friday, December 14, 2012 6:23:41 PM UTC-5, Eric Blake wrote: > Short answer: historical compatibility. 'set -e' has been specified to > behave the way it did 30 years ago in one reference implementation, and > while you can argue till you are blue in the face that the reference > implementation is not intuitive, you have to at least appreciate that > having a standard means you are likely to get the same (non-intuitive) > behavior among several competing shell implementations that all strive > to conform to POSIX. Thanks for the reply. I understand the benefits of a standard. In this case, it seems to me that the problem we're talking about- stopping a script as soon as a command returns an unexpected non-0 code- is a very basic feature that many could benefit from, if implemented right. I'm trying to understand whether or not fixing this problem requires changing the standard or not. My question 5 is about whether the standard itself requires that subsequent attempts to set errexit should be ignored, even assuming that errexit should be turned off once in a while for the sake of the standard. The alternative is that this is just a historical decision of bash that could be mended without breaking compliance. If indeed the standard requires all further attempts to set errexit be ignored (which I think is a terrible idea), wouldn't it be a good idea to provide in bash another option doing the same thing, but correctly? Something like set -o strong_errexit, something that anybody writing a new script can choose to use or not, of course understanding that it is a bashism, but the right kind of bashism. Also, my questions 1-3 relate to the current implementation...
Re: shouldn't /+(??) capture 2 letter files only?
>> > echo !(??|foo|bar) >> >> precisely where i started this thread, !(??) > > +(??) and !(??) are completely different things. !(??) was never mentioned in the original question, and should work as expected. yow, truly, you're saying +(??) selects *any multiple* of 2chars, but !(??) excludes 2char names *only*! sheesh. ok thanks.
Re: shouldn't /+(??) capture 2 letter files only?
On Sat, Dec 15, 2012 at 1:01 PM, gregrwm wrote: > >> > echo !(??|foo|bar) > >> > >> precisely where i started this thread, !(??) > > > > +(??) and !(??) are completely different things. !(??) was never > mentioned in the original question, and should work as expected. > > yow, truly, you're saying +(??) selects *any multiple* of 2chars, but > !(??) excludes 2char names *only*! sheesh. ok thanks. > +(foo) in extglob works the same way as (foo)+ in ERE. +(??) is therefore the same as (..)+, which indeed selects "one or more multiples of two characters". *(??) is then "0 or more multiples of two characters", just like (..)*. If you wanted to select only one instance of what's inside the parens, you want to use @(foo). That would be the same as simply (..) in ERE. !() is unique, POSIX RE has no equivalent. But it basically expands to '*, except for what's inside'. That sounds like what you're looking for to me.
Re: why does errexit exist in its current utterly useless form?
On 12/15/12 11:54 AM, matei.da...@gmail.com wrote: > On Friday, December 14, 2012 6:23:41 PM UTC-5, Eric Blake wrote: >> Short answer: historical compatibility. 'set -e' has been specified to >> behave the way it did 30 years ago in one reference implementation, and >> while you can argue till you are blue in the face that the reference >> implementation is not intuitive, you have to at least appreciate that >> having a standard means you are likely to get the same (non-intuitive) >> behavior among several competing shell implementations that all strive >> to conform to POSIX. > > Thanks for the reply. I understand the benefits of a standard. In this case, > it seems to me that the problem we're talking about- stopping a script as > soon as a command returns an unexpected non-0 code- is a very basic feature > that many could benefit from, if implemented right. I'm trying to understand > whether or not fixing this problem requires changing the standard or not. The behavior you want requires changing the standard. > My question 5 is about whether the standard itself requires that subsequent > attempts to set errexit should be ignored, even assuming that errexit should > be turned off once in a while for the sake of the standard. The alternative > is that this is just a historical decision of bash that could be mended > without breaking compliance. It does. The text in the (still-published) version of Posix-2008 was deemed to be wrong and not consistent with historical shell behavior; this is the updated version: http://austingroupbugs.net/view.php?id=52 The text in the first sentence of 2) implies that -e is ignored during the execution of the commands in the listed contexts. It doesn't matter what you do to the -e option while it's ignored. The shell will only pay attention to the setting of -e, whatever it is, when it's no longer executing in a context where -e is ignored. There is consensus among Posix and current shell implementations about this. There has been extensive discussion about this, some even on bug-bash: http://lists.gnu.org/archive/html/bug-bash/2011-06/msg00080.html http://lists.gnu.org/archive/html/bug-bash/2011-11/msg00125.html http://lists.gnu.org/archive/html/bug-bash/2012-01/msg00111.html http://lists.gnu.org/archive/html/bug-bash/2012-09/msg00014.html http://lists.gnu.org/archive/html/bug-bash/2012-10/msg00049.html There are bash users who are extremely vocal about their view that the bash-4.2 behavior, which was modified extensively to implement what Posix says and what historical shells do, is wrong, so you are not alone. > If indeed the standard requires all further attempts to set errexit be > ignored (which I think is a terrible idea), wouldn't it be a good idea to > provide in bash another option doing the same thing, but correctly? Something > like set -o strong_errexit, something that anybody writing a new script can > choose to use or not, of course understanding that it is a bashism, but the > right kind of bashism. There is already a proposal for a new option similar to what you want; you can read the discussion at http://austingroupbugs.net/view.php?id=537 Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Questions to bash "read" builtin functionality
On 12/14/12 6:28 AM, Fiedler Roman wrote: > Hello list, > > One of our bash-scrips failed with very low frequency but randomly. The > result was that exactly 1 byte was lost, so the string returned by "read -t > 1" was too short. The culprit seems to be the built-in read function itself, > the probability of failure was about 1:10 in our case. > > After analysis and creation of a reliable reproducer, I'm not sure if this is > a programming error in bash or a bug in our script as the result of > suboptimal documentation. > > * Description: > > When "read" builtin is used with timeout setting, both with "-t" option or by > setting the "TMOUT" environment variable, and the timeout occurs when some > bytes of line were already received by bash, then those bytes are silently > dropped. The next "read" returns the remainder of the line. You don't say what version of bash you're using, but the following change went in with bash-4.0: k. Changed the behavior of the read builtin to save any partial input received in the specified variable when the read builtin times out. This also results in variables specified as arguments to read to be set to the empty string when there is no input available. When the read builtin times out, it returns an exit status greater than 128. That is not clearly stated in the manual's description of `read'. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Requesting an alternate nameref feature
On 12/12/12 1:04 PM, Dan Douglas wrote: > Hello. Could we possibly modify or create an additional variant of "typeset > -n" > which produces "real" references rather than just dynamic references by name? > In other words, I'd like to be able to create reference variables that always > point to the instance of a variable that was visible at the time the reference > was created, similar to the way ksh93's nameref works. This is the `pointer' implementation, as opposed to the `symbolic link' implementation I chose. The problem is the same as any use of pointers: what happens when the object you point to goes out of scope? Or would you restrict it, like declare -g, to only use the global scope? Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: loadable support for HP-UX 10 (bash 4.2)
On 10/5/12 9:19 AM, Greg Wooledge wrote: > Here's an updated version of a patch I did a few years ago to add loadable > support for bash under HP-UX 10. The previous patch was for bash 4.0. > This one has been updated for bash 4.2. It is fundamentally the same > patch, just with different context and line numbers and stuff, so that > it applies cleanly. Thanks. I'd prefer to use something like the `library' implmentation of the dl* family of functions in CWRU/misc/hpux10-dlfcn.h. I have it, but don't have any way to test it. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Trap variable scope
On 11/2/12 10:48 AM, Nikolai Kondrashov wrote: > Hi everyone, > > I've encountered a very strange behavior regarding variable scope and traps, > which looks very much like a bug. This will be fixed, to the extent that identical blocks of code like the two below will do the same thing, in the next release. The problem was the code that runs the command for `bash -c' was not treating the jump on ERREXIT identically to the main reader loop. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: why does errexit exist in its current utterly useless form?
On Saturday, December 15, 2012 5:23:04 PM UTC-5, Chet Ramey wrote: > There is already a proposal for a new option similar to what you want; you > can read the discussion at > > http://austingroupbugs.net/view.php?id=537 Thank you for all the references, I'll have a look!
