Re: Unhelpful behaviors in 4.2.10(1)

[Linda Walsh]

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