|
From: | Linda Walsh |
Subject: | Re: Unhelpful behaviors in 4.2.10(1) |
Date: | Sat, 09 Jun 2012 15:09:40 -0700 |
User-agent: | Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.24) Gecko/20100228 Lightning/0.9 Thunderbird/2.0.0.24 Mnenhy/0.7.6.666 |
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)....
[Prev in Thread] | Current Thread | [Next in Thread] |