[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
- Unhelpful behaviors in 4.2.10(1), Linda Walsh, 2012/06/08
- Re: Unhelpful behaviors in 4.2.10(1),
Pierre Gaston <=
- Re: Unhelpful behaviors in 4.2.10(1), Linda Walsh, 2012/06/09
- Re: Unhelpful behaviors in 4.2.10(1), Pierre Gaston, 2012/06/09
- Re: Unhelpful behaviors in 4.2.10(1), Chet Ramey, 2012/06/09
- Re: Unhelpful behaviors in 4.2.10(1), Linda Walsh, 2012/06/09
- Re: bash giving wrong message for indicated failure (was Re: Unhelpful behaviors in 4.2.10(1)), Linda Walsh, 2012/06/13
- Re: bash giving wrong message for indicated failure (was Re: Unhelpful behaviors in 4.2.10(1)), Chet Ramey, 2012/06/14
- Re: bash giving wrong message for indicated failure (was Re: Unhelpful behaviors in 4.2.10(1)), Linda Walsh, 2012/06/14