[Top][All Lists]

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

Re: bash giving wrong message for indicated failure (was Re: Unhelpful b

From: Linda Walsh
Subject: Re: bash giving wrong message for indicated failure (was Re: Unhelpful behaviors in 4.2.10(1))
Date: Wed, 13 Jun 2012 15:05:38 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/20100228 Lightning/0.9 Thunderbird/ Mnenhy/

Reference original problem:
----- Begin File1 (sdf) ----------------

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

[[ $# -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 
give a reason for the error leading the user to a correct solution for their

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

reply via email to

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