Date: Wed, 18 Mar 1998 03:00:02 -0800 (PST) From: Studded <Studded@dal.net> To: freebsd-bugs Subject: Re: bin/6047: bash does not handle -e option properly Message-ID: <199803181100.DAA11065@hub.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/6047; it has been noted by GNATS.
From: Studded <Studded@dal.net>
To: Bruce Evans <bde@zeta.org.au>
Cc: dancy@franz.com, freebsd-bugs@FreeBSD.ORG,
freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: bin/6047: bash does not handle -e option properly
Date: Wed, 18 Mar 1998 02:58:24 -0800
Bruce Evans wrote:
> ---
> #!/bin/sh
> set -e
> funcfalse() {
> return 1
> }
>
> for i in /usr/bin/false false funcfalse
> do
> if $i; then echo $i; else echo not $i; fi
> done
> ---
When I run this, I get:
$ testpr
not /usr/bin/false
not false
$
I'm not sure what you're getting at here, since it seems to me that
what you really want to test is the value of `false` rather than the
string "false," but like I said, I think I'm missing something. My
understanding is that "exit codes" should be numbers, "zero for normal
or success, and non-zero for failure, error, or a false indication" to
quote the man page for sh.
> This handles funcfalse different from the other falses. /bin/sh apparently
> exits for `return 1' when -e is set.
No, sh exits for the exit status of funcfalse being '1'. Return is a
builtin whose only job is to terminate and report the exit status of the
function.
> The correctness of this for a POSIX
> shhell depends on whether `return' is a simple command. I don't think it
> is. This examples shows why it shouldn't be.
Here is a more detailed example:
#!/bin/sh
set -e
testtrue () {
true
return $?
}
testfalse () {
false
return $?
}
echo 'First test inside a function, we know it will work'
if testtrue ; then
echo 'See, it worked'
fi
# Run the first time with this uncommented,
# then comment and run again.
echo 'Second test inside a function, we should continue on after this'
if testfalse; then
echo 'You should not see this because the condition is false'
fi
echo 'First test w/o function, we know it will work'
if true; then
echo 'See, it worked'
fi
echo 'Second test w/o function, we should continue on after this'
if false; then
echo 'You should not see this because the condition is false'
fi
echo 'First untested command, we know it will work'
true
echo " Exit status of first test is: $? "
echo 'Second untested command, we should exit after this'
false
echo " If you can see this, set is broken in sh"
The commented section demonstrates what I think the point of contention
is. The shell is handling functions differently than it is handling
"commands." My initial response was based on my belief that this was the
desired behaviour. You however are in a much better position to deal
with the POSIX definitions of those terms than I am, so I bow to your
expertise. If a "function" is not a "command," then set -e is working as
advertised, if not as we'd expect. If the terms are equivalent, there is
a bug. I suspect that the terms are equivalent and that my initial
response was incorrect based on the fact that bash handles the whole
script and doesn't exit at the false tested function.
The reason I asked what the PR originator was trying to accomplish was
to offer my assistance in accomplishing the actual goal (which I doubt
was to test various permutations of shell settings :). The offer is
still open.
Doug
--
*** Chief Operations Officer, DALnet IRC network ***
*** Proud operator, designer and maintainer of the world's largest
*** Internet Relay Chat server. 5,328 clients and still growing.
*** Try spider.dal.net on ports 6662-4 (Powered by FreeBSD)
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199803181100.DAA11065>