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)....
