bug-bash
[Top][All Lists]
Advanced

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

Re: Unhelpful behaviors in 4.2.10(1)


From: Pierre Gaston
Subject: Re: Unhelpful behaviors in 4.2.10(1)
Date: Sat, 9 Jun 2012 07:00:15 +0300

On Sat, Jun 9, 2012 at 4:01 AM, Linda Walsh <bash@tlinx.org> wrote:
> File1:
> sdf:
> Ishtar:/tmp> more 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
> --------------------------------
> file2: sdf2
> #!/bin/bash
>
>
> [[ $# -ge 2 ]] && echo weird
>
> --------------------------------
> running:
> Ishtar:/tmp> sdf
>  Error executing "[[ $# -ge 2 ]]" in "main"
>    at "./sdf", line "4" (level=0)
> ---
>
>
> So why am I getting a backtrace (and how do I make it put out the right
> file)?
> I thought rather than something just dying -- it would be nice to know how
> it got there... so...backtrace... but the line it is complaining about
> is in "sdf2" --- and WTF?... how is testing a number an error that would
> cause a
> exception?
>
> (if this was running under -e, I presume that if statements that are false
> now fail?... )...I thought complex statements were not supposed to fail
>
> POSIX really F-U'ed on this one... go back to bash 2's "simple
> statements"...
> having conditional statements fail is going overboard...
> I mean it's an explicit check to avoid an error condition...so, of course,
> such checks are now errors?!?!?!....ARG *hitting head against wall....***
>
> file:
> backtrace.shh:
>
>>  more /home/law/bin/lib/backtrace.shh
>
> #!/bin/bash
> function backtrace {
>
>  declare -i level=0
>  while {
>     local cmd=$BASH_COMMAND
>     local fn=${FUNCNAME[level+1]:-}
>     local src=${BASH_SOURCE[level+1]:-}
>     local ln=${BASH_LINENO[level]:-}
>   }; do
>     [[ -n $fn && -n $src && -n $ln  ]] && {
>       echo "  Error executing \"$cmd\" in \"$fn\""
>       echo "     at \"$src\", line \"$ln\" (level=$level)"
>       level+=1
>       continue;
>     }
>     exit 1
>   done
> }
>
> trap backtrace ERR
> set -T
>

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.

The same thing happens with a function, eg you'll probably get the
same result with:
foo () { false && echo foo; }

It kinda make sense to me.

For what it's worth in bash 2.05b.0(1)-release:

echo '[[ $# -ge 2 ]] && echo foo' > sdf2;
( set -e; . ./sdf2;echo bar)

prints nothing...so I guess it's not that new



reply via email to

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