[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Unhelpful behaviors in 4.2.10(1)

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: Gecko/20100228 Lightning/0.9 Thunderbird/ Mnenhy/

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:


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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]