From nobody  Tue Mar 17 17:04:26 1998
Received: (from nobody@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id RAA13084;
          Tue, 17 Mar 1998 17:04:26 -0800 (PST)
          (envelope-from nobody)
Message-Id: <199803180104.RAA13084@hub.freebsd.org>
Date: Tue, 17 Mar 1998 17:04:26 -0800 (PST)
From: dancy@franz.com
To: freebsd-gnats-submit@freebsd.org
Subject: bash does not handle -e option properly
X-Send-Pr-Version: www-1.0

>Number:         6047
>Category:       bin
>Synopsis:       bash does not handle -e option properly
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Mar 17 17:10:01 PST 1998
>Closed-Date:    Mon May 4 09:26:52 MEST 1998
>Last-Modified:  Mon May  4 09:27:50 MEST 1998
>Originator:     Ahmon Dancy
>Release:        3.0-971225-SNAP
>Organization:
Franz Inc.
>Environment:
FreeBSD news2.franz.com 3.0-971225-SNAP FreeBSD 3.0-971225-SNAP #0: Mon Feb 23 08:20:57 PST 1998     root@news2.franz.com:/usr/src/sys/compile/NEWS  i386

>Description:
The following shell script does not work as it should:

#!/bin/sh
set -e

is_net_dir_p()
{
        case $1 in
        /net/*)
                return 0
                ;;
        *)      return 1
                ;;
        esac
}


if is_net_dir_p freebsd; then
        echo okay
fi
echo done

---
A properly working /bin/sh would print 'done' and exit.  Currently
nothing is printed and the shell silently exits.

The man page for 'sh' says:

     -e errexit
             If not interactive, exit immediately if any untested command
             fails.  The exit status of a command is considered to be explic-
             itly tested if the command is used to control an if, elif, while,
             or until; or if the command is the left hand operand of an ``&&''
             or ``||'' operator.

>How-To-Repeat:
Run my script above.

>Fix:

>Release-Note:
>Audit-Trail:

From: Studded <Studded@dal.net>
To: dancy@franz.com
Cc: freebsd-gnats-submit@freebsd.org, freebsd-bugs@freebsd.org
Subject: Re: bin/6047: bash does not handle -e option properly
Date: Tue, 17 Mar 1998 23:59:56 -0800

 dancy@franz.com wrote:
 > 
 > >Number:         6047
 > >Category:       bin
 > >Synopsis:       bash does not handle -e option properly
 
 	Bash != /bin/sh
 
 > >Description:
 > The following shell script does not work as it should:
 > 
 > #!/bin/sh
 > set -e
 > 
 > is_net_dir_p()
 > {
 >         case $1 in
 >         /net/*)
 >                 return 0
 >                 ;;
 >         *)      return 1
 >                 ;;
 >         esac
 > }
 > 
 > if is_net_dir_p freebsd; then
 >         echo okay
 > fi
 > echo done
 > 
 > ---
 > A properly working /bin/sh would print 'done' and exit.  Currently
 > nothing is printed and the shell silently exits.
 > 
 > The man page for 'sh' says:
 > 
 >      -e errexit
 >              If not interactive, exit immediately if any untested command
 >              fails.  The exit status of a command is considered to be explic-
 >              itly tested if the command is used to control an if, elif, while,
 >              or until; or if the command is the left hand operand of an ``&&''
 >              or ``||'' operator.
 
 	Actually it's doing just what it should. Your function fails, so the
 shell should exit silently. You can demonstrate by commenting out the
 set line and running the script again. Also, I'm not sure what /net/* is
 supposed to be testing for, but that looks an awful lot like you're
 mixing perl syntax with sh. 
 
 	What are you actually trying to accomplish here?
 
 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)

From: Bruce Evans <bde@zeta.org.au>
To: dancy@franz.com, Studded@dal.net
Cc: 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 20:24:24 +1100

 >	What are you actually trying to accomplish here?
 
 He's trying to to get sh fixed to work properly.  Perhaps a better
 example:
 
 ---
 #!/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
 ---
 
 This handles funcfalse different from the other falses.  /bin/sh apparently
 exits for `return 1' when -e is set.  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.
 
 The PR should not mention bash in its subject line.  bash works right,
 but /bin/sh doesn't.
 
 Bruce

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)

From: Ahmon Dancy <dancy@franz.com>
To: Studded <Studded@dal.net>
Cc: freebsd-gnats-submit@freebsd.org, freebsd-bugs@freebsd.org
Subject: Re: bin/6047: bash does not handle -e option properly 
Date: Wed, 18 Mar 1998 08:04:42 -0800

 >> dancy@franz.com wrote:
 >> > 
 >> > >Number:         6047
 >> > >Category:       bin
 >> > >Synopsis:       bash does not handle -e option properly
 >> 
 >> 	Bash != /bin/sh
 
 Indeed..  I have the bad habit of calling 'sh' bash.  I'm definitely
 talking about /bin/sh here.

From: Ahmon Dancy <dancy@franz.com>
To: Studded <Studded@dal.net>
Cc: Bruce Evans <bde@zeta.org.au>, 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 08:14:27 -0800

 Hi guys.
 
 
 >> 	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. 
 
 Exactly.. And the man page for 'sh' reports that if this return value
 is tested (such as within an 'if' statement like in my example), then
 the shell should not exit.
 
 
 >> 	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. 
 
 Thanks for the offer. :)  The piece of code I submitted was just a
 chunk of code that works right on every other platform (Solaris, AIX,
 HP/UX, SunOS, Irix, Linux) except for FreeBSD.  As the name implies
 (in a LISPish manner), it's testing to see whether the argument
 (expected to be a pathname) is on an automounted NFS filesystem
 (/net/hostname/x/y/x).  
 
 
 
 
 
 

From: Ahmon Dancy <dancy@franz.com>
To: Bruce Evans <bde@zeta.org.au>
Cc: Studded@dal.net, freebsd-bugs@freebsd.org,
        freebsd-gnats-submit@freebsd.org
Subject: Re: bin/6047: /bin/sh does not handle -e option properly 
Date: Fri, 03 Apr 1998 08:25:12 -0800

 Hey dudes, what's the latest status on this? 

From: Martin Cracauer <cracauer@cons.org>
To: Ahmon Dancy <dancy@franz.com>, Bruce Evans <bde@zeta.org.au>
Cc: Studded@dal.net, freebsd-bugs@FreeBSD.ORG,
        freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: bin/6047: /bin/sh does not handle -e option properly
Date: Sat, 4 Apr 1998 12:03:51 +0200

 --AqsLC8rIMeq19msA
 Content-Type: text/plain; charset=us-ascii
 
 In <199804031625.IAA10622@ultra.franz.com>, Ahmon Dancy wrote: 
 > Hey dudes, what's the latest status on this? 
 
 [My last reply didn't make it into the bug database, sorry if you see
 this twice]. 
 
 Could you please test the appended fix? It fixes the particual  
 problem, the question is what else it br(e)ak(e)s :-)           
  
 In case you don't want to build a shell, I put a binary with this fix
 on
 http://www.freebsd.org/~cracauer/sh.gz
          
 Happy Lisping                                                     
         Martin
 -- 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 Martin Cracauer <cracauer@cons.org> http://www.cons.org/cracauer
   cracauer@wavehh.hanse.de (batched, preferred for large mails)
   Tel.: (daytime) +4940 41478712 Fax.: (daytime) +4940 41478715
   Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536
   Paper: (private) Waldstrasse 200, 22846 Norderstedt, Germany
 
 --AqsLC8rIMeq19msA
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: attachment; filename=diff
 
 *** /usr/src/bin/sh/eval.c	Wed Mar 25 16:43:53 1998
 --- eval.c	Fri Apr  3 20:32:12 1998
 ***************
 *** 764,770 ****
   		for (sp = varlist.list ; sp ; sp = sp->next)
   			mklocal(sp->text);
   		funcnest++;
 ! 		evaltree(cmdentry.u.func, 0);
   		funcnest--;
   		INTOFF;
   		poplocalvars();
 --- 764,773 ----
   		for (sp = varlist.list ; sp ; sp = sp->next)
   			mklocal(sp->text);
   		funcnest++;
 ! 		if (flags & EV_TESTED)
 ! 			evaltree(cmdentry.u.func, EV_TESTED);
 ! 		else
 ! 			evaltree(cmdentry.u.func, 0);
   		funcnest--;
   		INTOFF;
   		poplocalvars();
 
 --AqsLC8rIMeq19msA--

From: Ahmon Dancy <dancy@franz.com>
To: Martin Cracauer <cracauer@cons.org>
Cc: Bruce Evans <bde@zeta.org.au>, Studded@dal.net, freebsd-bugs@freebsd.org,
        freebsd-gnats-submit@freebsd.org
Subject: Re: bin/6047: /bin/sh does not handle -e option properly 
Date: Sat, 04 Apr 1998 08:37:12 -0800

 This new code makes my script work properly.
 
 
 >> 
 >> --AqsLC8rIMeq19msA
 >> Content-Type: text/plain; charset=us-ascii
 >> 
 >> In <199804031625.IAA10622@ultra.franz.com>, Ahmon Dancy wrote: 
 >> > Hey dudes, what's the latest status on this? 
 >> 
 >> [My last reply didn't make it into the bug database, sorry if you see
 >> this twice]. 
 >> 
 >> Could you please test the appended fix? It fixes the particual  
 >> problem, the question is what else it br(e)ak(e)s :-)           
 >>  
 >> In case you don't want to build a shell, I put a binary with this fix
 >> on
 >> http://www.freebsd.org/~cracauer/sh.gz
 >>          
 >> Happy Lisping                                                     
 >>         Martin
 >> -- 
 >> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 >> Martin Cracauer <cracauer@cons.org> http://www.cons.org/cracauer
 >>   cracauer@wavehh.hanse.de (batched, preferred for large mails)
 >>   Tel.: (daytime) +4940 41478712 Fax.: (daytime) +4940 41478715
 >>   Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536
 >>   Paper: (private) Waldstrasse 200, 22846 Norderstedt, Germany
 >> 
 >> --AqsLC8rIMeq19msA
 >> Content-Type: text/plain; charset=us-ascii
 >> Content-Disposition: attachment; filename=diff
 >> 
 >> *** /usr/src/bin/sh/eval.c	Wed Mar 25 16:43:53 1998
 >> --- eval.c	Fri Apr  3 20:32:12 1998
 >> ***************
 >> *** 764,770 ****
 >>   		for (sp = varlist.list ; sp ; sp = sp->next)
 >>   			mklocal(sp->text);
 >>   		funcnest++;
 >> ! 		evaltree(cmdentry.u.func, 0);
 >>   		funcnest--;
 >>   		INTOFF;
 >>   		poplocalvars();
 >> --- 764,773 ----
 >>   		for (sp = varlist.list ; sp ; sp = sp->next)
 >>   			mklocal(sp->text);
 >>   		funcnest++;
 >> ! 		if (flags & EV_TESTED)
 >> ! 			evaltree(cmdentry.u.func, EV_TESTED);
 >> ! 		else
 >> ! 			evaltree(cmdentry.u.func, 0);
 >>   		funcnest--;
 >>   		INTOFF;
 >>   		poplocalvars();
 >> 
 >> --AqsLC8rIMeq19msA--
 >> 
 
State-Changed-From-To: open->closed 
State-Changed-By: cracauer 
State-Changed-When: Mon May 4 09:26:52 MEST 1998 
State-Changed-Why:  
Fixed in -current and RELENG_2_2 
>Unformatted:
