Re: Unhelpful behaviors in 4.2.10(1)
Pierre Gaston wrote: trap backtrace ERR set -T To sum up ". sdf2" is returning 1 Bash considers . to be a simple command even though what's really executed is [[ $# -ge 2 ]] && echo hello. --- Right It's NOT a simple command. I am trapping on ERR, not 'anything' that is not zero. Of all the stupid definitions... you have 256 useful values to return, and some idiots decide 255 of them should be reserved for fatal errors (even when they are not errors)... Is this even fixable?
Re: Unhelpful behaviors in 4.2.10(1)
On Sat, Jun 9, 2012 at 10:05 AM, Linda Walsh wrote: > > > Pierre Gaston wrote: >> >> >>> trap backtrace ERR >>> set -T >>> >> >> To sum up ". sdf2" is returning 1 >> Bash considers . to be a simple command even though what's really >> executed is [[ $# -ge 2 ]] && echo hello. > > --- > Right It's NOT a simple command. > > I am trapping on ERR, not 'anything' that is not zero. > > Of all the stupid definitions... you have 256 useful values to return, and > some > idiots decide 255 of them should be reserved for fatal errors (even when > they are > not errors)... > > Is this even fixable? Sorry if I was unclear but it is the "." command that causes the error. If you add "return 0" at the end of sdf2, you will see no trace. I would probably consider it a bug if "." was returning 1 without triggering an error. Now you could consider a bug to get the "[[ $# -ge 2 ]]" instead of "." in BASH_COMMAND, though I guess some people might, on the contrary, find it useful.
Re: Unhelpful behaviors in 4.2.10(1)
On 6/9/12 3:05 AM, Linda Walsh wrote: > >> To sum up ". sdf2" is returning 1 >> Bash considers . to be a simple command even though what's really >> executed is [[ $# -ge 2 ]] && echo hello. > --- > Right It's NOT a simple command. To be clear: `.' is a shell builtin, with its own semantics and exit status: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_18 Like any other builtin, it's a simple command when executed as one. And like any other builtin, if it returns a non-zero exit status when errexit is enabled, the shell will exit. 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: Unhelpful behaviors in 4.2.10(1)
Chet Ramey wrote: On 6/9/12 3:05 AM, Linda Walsh wrote: To sum up ". sdf2" is returning 1 Bash considers . to be a simple command even though what's really executed is [[ $# -ge 2 ]] && echo hello. --- Right It's NOT a simple command. To be clear: `.' is a shell builtin, with its own semantics and exit status: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_18 Like any other builtin, it's a simple command when executed as one. And like any other builtin, if it returns a non-zero exit status when errexit is enabled, the shell will exit. That's fine -- if the error message points at the included file as "not returning a 'true' value. It doesn't. It points to a conditional in the previous file. Perl issues a "FAIL" if you don't return true from including a module and people always make sure to add a '1' at the end of their module. If bash wants to require similar, then have it report WHY it is failing -- not pointing at a statement in the previous file that looks like it is doing what it is supposed to be doing. Though -- for consistency, why doesn't the filename point to the statement shown that possesses the line number that is given? That's also a bit misleading. Half my problems in perl would just "go away", if it gave read error messages that pointed to the real problem rather than perfectly valid statements 50-100 lines away (if they are even in the same file)
