Re: bash giving wrong message for indicated failure (was Re: Unhelpful behaviors in 4.2.10(1))

[Linda Walsh]

Reference original problem:
========================================================================
> ----- Begin File1 (sdf) ----------------
> #!/bin/bash
>
> _prgpth="${0:?}"; _prg="${_prgpth##*}"; _prgdr="${_prgpth%/$_prg}"
> [[ -z $_prgdr || $_prg == $_prgdr ]] && $_prgdr="$PWD"
> export PATH="$_prgdr/lib:$_prgdr:$PATH"
> shopt -s expand_aliases extglob sourcepath ; set -o pipefail
>
> . backtrace.shh
>
> . sdf2
> ------- End File1 (sdf) ----------------
> ------- Begin File2 (sdf2) -------------
> #!/bin/bash
>
>
> [[ $# -ge 2 ]] && echo weird
>
> ------- End File2 (sdf2) ----------------
>
> Execution output:
> ----------------
> $ sdf
>  Error executing "[[ $# -ge 2 ]]" in "main" <<<- wrong statement
>     at "./sdf", line "4" (level=0)            <<<- wrong file & line #
> ---
========================================================================

Linda Walsh wrote:
> Chet Ramey wrote:

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


  Is something that can be fixed?

  It really would be helpful for error messages to point at the actual problem 
and
give a reason for the error leading the user to a correct solution for their
code.

   I.e. as it stands, the above _looks_ like it doesn't like the conditional,
so I'd be inclined to rewrite the conditional as a negative, just to get
around a "BASH problem" (in this case, the fact that it points to the wrong
statement is really the problem).  Unfortunately, this wouldn't lead to
any greater understanding of the issue for the user nor give them the essential
information that "." and "source" are treated like commands and are not "simply"
"include" statements -- which is how I /tended/ to think of them (even though 
they
are more akin to an 'eval' of the included contents, sorta, though I wouldn't
be sure about that being entirely accurate either.  ;-/

  But having the error point to the "." or "source" and say the command didn't 
return
a 0 status, would be very clear.