From owner-freebsd-bugs  Wed Mar 18 03:00:04 1998
Return-Path: <owner-freebsd-bugs@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id DAA11107
          for freebsd-bugs-outgoing; Wed, 18 Mar 1998 03:00:04 -0800 (PST)
          (envelope-from owner-freebsd-bugs@FreeBSD.ORG)
Received: (from gnats@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id DAA11065;
          Wed, 18 Mar 1998 03:00:02 -0800 (PST)
          (envelope-from gnats)
Date: Wed, 18 Mar 1998 03:00:02 -0800 (PST)
Message-Id: <199803181100.DAA11065@hub.freebsd.org>
To: freebsd-bugs
Cc: 
From: Studded <Studded@dal.net>
Subject: Re: bin/6047: bash does not handle -e option properly
Reply-To: Studded <Studded@dal.net>
Sender: owner-freebsd-bugs@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

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