Debian bug report logs - #1151
bash exit status incorrect - seriously affects dpkg upgrade

Message received at debian-bugs:

From cus.cam.ac.uk!iwj10 Wed Jul 26 06:35:24 1995
Return-Path: <iwj10@cus.cam.ac.uk>
Received: from pixar.com by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0sb6cO-000BYXC; Wed, 26 Jul 95 06:35 PDT
Received: from bootes.cus.cam.ac.uk by pixar.com with SMTP id AA14944
  (5.67b/IDA-1.5 for debian-bugs-pipe@mongo.pixar.com); Wed, 26 Jul 1995 06:33:48 -0700
Received: by bootes.cus.cam.ac.uk 
	(Smail-3.1.29.0 #36) id m0sb6cJ-000C0RC; Wed, 26 Jul 95 14:35 BST
Received: by chiark
	id <m0savVx-0002XuZ@chiark.al.cl.cam.ac.uk>
	(Debian /\oo/\ Smail3.1.29.1 #29.32); Wed, 26 Jul 95 02:44 BST
Message-Id: <m0savVx-0002XuZ@chiark.al.cl.cam.ac.uk>
Date: Wed, 26 Jul 95 02:44 BST
From: iwj10@cus.cam.ac.uk (Ian Jackson)
To: debian-bugs@pixar.com
Subject: Re: Bug#1151: bash exit status incorrect - seriously affects dpkg upgrade

Bill Mitchell writes:
> [...]
>   Are we justified in assuming that /bin/sh will be bash?
> [...]

No.  If we write bash-specific scripts we should say `#!/bin/bash', so
that they at least fail sanely when sh is not bash.

However, as I said earlier I'll continue to consider this exit status
behavour a bug until and unless I discover that there's a standard
requiring it.

Ian.

Message received at debian-bugs:

From mdd.comm.mot.com!mitchell Tue Jul 25 07:23:33 1995
Return-Path: <mitchell@mdd.comm.mot.com>
Received: from pixar.com by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0saktL-000BHbC; Tue, 25 Jul 95 07:23 PDT
Received: from motgate.mot.com by pixar.com with SMTP id AA14311
  (5.67b/IDA-1.5 for debian-bugs-pipe@mongo.pixar.com); Tue, 25 Jul 1995 07:21:53 -0700
Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (8.6.11/8.6.10/MOT-3.7) with ESMTP id JAA06298; Tue, 25 Jul 1995 09:23:23 -0500
Received: from mdd.comm.mot.com (mdisea.mdd.comm.mot.com [138.242.64.201]) by pobox.mot.com (8.6.11/8.6.10/MOT-3.7) with SMTP id JAA27489; Tue, 25 Jul 1995 09:23:22 -0500
Received: from bb29c.mdd.comm.mot.com by mdd.comm.mot.com (4.1/SMI-4.1)
	id AA27978; Tue, 25 Jul 95 07:23:19 PDT
Received: by bb29c.mdd.comm.mot.com (4.1/SMI-4.1)
	id AA23797; Tue, 25 Jul 95 07:23:11 PDT
Date: Tue, 25 Jul 95 07:23:11 PDT
From: mitchell@mdd.comm.mot.com (Bill Mitchell)
Message-Id: <9507251423.AA23797@bb29c.mdd.comm.mot.com>
To: richard@elmail.co.uk, debian-bugs@pixar.com
Subject: Re: Bug#1151: bash exit status incorrect - seriously affects dpkg upgrade

Richard Kettlewell <richard@elmail.co.uk>

> > The sh(1) man page on this SunOS sytem says:
> >
> >   DESCRIPTION
> >        sh, the Bourne shell, is the  standard  UNIX-system  command
> >        interpreter.  It executes commands read from a terminal or a
> >        file.
> 
> Read the full manual:
> 
>      exit [ n ]     Exit a shell with the exit  status  specified
>                     by  n.   If  n  is omitted the exit status is
>                     that of the last  command  executed  (an  EOF
>                     will also cause the shell to exit.)

My point was not what performance the man page claimed, but that the
man page seened to claim a genuine Bourne shell, and that it behaved
differently than the bahavior desired by the bug report.

> ...if we're quoting Sun man pages then it's a bug in Sun's sh as well.

May be.  As I went on to say:

> > I don't know what the Posix standard may or may not have to say about

I've seen enough bugs and ambiguities in man pages to know that they're
likely not a good reference about what a program is supposed to do when
you get down to the nitty-gritty.  You contend that, in both the Sun sh
case and the bash case, the man page is right and the program is wrong.
May be.  I did look at the bash source code, and the exit status
on an exit trap looks pretty explicit.  I don't have a copy of the
older bash code which behaved as desired handy for comparson, so
can't make a good guess about whether the change was an introduced
bug or deliberate.

> > this, but it looks as if we may be expecting bash-man-page-specific
> > behavior from /bin/sh.  Are we justified in assuming that /bin/sh
> > will be bash?
>
> When was the last time you saw a Linux system on which sh was not bash?
> I've never knowingly seen one...

The last time I installed debian, I think.  (is it ash, or what?).

Even if I've never seen one, the question stands.  Are we justified in
assuming that /bin/sh will be bash?  I'm aware that the shell will be
bash in an overwhelming majority of cases, and that that situation is
even likely to stay stable for the forseeable future.  Still, the
question stands.  Are we justified in assuming that /bin/sh will be
bash?  

Message received at debian-bugs:

From elmail.co.uk!richard Tue Jul 25 01:47:07 1995
Return-Path: <richard@elmail.co.uk>
Received: from pixar.com by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0safdm-0005TGC; Tue, 25 Jul 95 01:47 PDT
Received: from tlingit.elmail.co.uk by pixar.com with SMTP id AA26963
  (5.67b/IDA-1.5 for debian-bugs-pipe@mongo.pixar.com); Tue, 25 Jul 1995 01:45:08 -0700
Received: from mojave.elmail.co.uk by tlingit.elmail.co.uk (8.6.11) id JAA03871; Tue, 25 Jul 1995 09:45:13 +0100
Date: Tue, 25 Jul 1995 09:49:58 +0100 (BST)
From: Richard Kettlewell <richard@elmail.co.uk>
To: debian-bugs@pixar.com
Subject: Re: Bug#1151: bash exit status incorrect - seriously affects dpkg upgrade
In-Reply-To: <9507242115.AA23182@bb29c.mdd.comm.mot.com>
Message-Id: <Pine.SUN.3.91.950725094136.22435B-100000@mojave.elmail.co.uk>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 24 Jul 1995, Bill Mitchell wrote:
> iwj10@cus.cam.ac.uk (Ian Jackson) said:
> > Package: bash
> > Version: 1.14.4-1
> >
> > chiark:~/junk> cat t
> > #!/bin/sh -
> > trap "true" 0
> > exit 1
> > chiark:~/junk> ./t
> > chiark:~/junk> echo $?
> > 0
> > chiark:~/junk>
> >
> > According to the manpage entry for `exit' it causes the shell to exit
> > with the status specified; it is only supposed to use that of the last
> > command executed if no status is specified (and even then IMO it [...]
> 
> This does appear to be a bash bug, in that this version of bash is not
> behaving as its man page says it does, nor as some earlier bash versions
> behaved.
> 
> However, the "#!/bin/sh" line in the script bothers me, in that that it
> presumes that this /bin/sh is bash.
> 
> I did the following experiment:
> 
>     bb29c /h/bb/mitchell/x> sh -x x
>     + trap true 0
>     + exit 1
>     + true
>     bb29c /h/bb/mitchell/x> echo $?
>     0
>     bb29c /h/bb/mitchell/x> uname -a
>     SunOS bb29c 4.1.3 1 sun4c
> 
> The sh(1) man page on this SunOS sytem says:
> 
>   DESCRIPTION
>        sh, the Bourne shell, is the  standard  UNIX-system  command
>        interpreter.  It executes commands read from a terminal or a
>        file.

Read the full manual:

     exit [ n ]     Exit a shell with the exit  status  specified
                    by  n.   If  n  is omitted the exit status is
                    that of the last  command  executed  (an  EOF
                    will also cause the shell to exit.)

...if we're quoting Sun man pages then it's a bug in Sun's sh as well.  I
see no reason why Debian, or anything else for that matter, should aim to
be so compatible with anything that it starts implementing its bugs as
well as its features.

(uname -a says `SunOS mojave 4.1.3_U1 1 sun4m' here.)

> On this system, which claims to offer a standard Bourne shell, we see
> results which differ from the desired (and advertised) results from
> bash when executing this script.

Perhaps someone would like to check if they fixed it in Solaris 2.

> I don't know what the Posix standard may or may not have to say about
> this, but it looks as if we may be expecting bash-man-page-specific
> behavior from /bin/sh.  Are we justified in assuming that /bin/sh
> will be bash?

When was the last time you saw a Linux system on which sh was not bash?  
I've never knowingly seen one...

ttfn/rjk

Message received at debian-bugs:

From mdd.comm.mot.com!mitchell Mon Jul 24 14:19:40 1995
Return-Path: <mitchell@mdd.comm.mot.com>
Received: from pixar.com by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0saUuX-00063SC; Mon, 24 Jul 95 14:19 PDT
Received: from motgate.mot.com by pixar.com with SMTP id AA09117
  (5.67b/IDA-1.5 for debian-bugs-pipe@mongo.pixar.com); Mon, 24 Jul 1995 14:17:59 -0700
Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (8.6.11/8.6.10/MOT-3.7) with ESMTP id QAA08549; Mon, 24 Jul 1995 16:15:29 -0500
Received: from mdd.comm.mot.com (mdisea.mdd.comm.mot.com [138.242.64.201]) by pobox.mot.com (8.6.11/8.6.10/MOT-3.7) with SMTP id QAA16032; Mon, 24 Jul 1995 16:15:28 -0500
Received: from bb29c.mdd.comm.mot.com by mdd.comm.mot.com (4.1/SMI-4.1)
	id AA25691; Mon, 24 Jul 95 14:15:26 PDT
Received: by bb29c.mdd.comm.mot.com (4.1/SMI-4.1)
	id AA23182; Mon, 24 Jul 95 14:15:21 PDT
Date: Mon, 24 Jul 95 14:15:21 PDT
From: mitchell@mdd.comm.mot.com (Bill Mitchell)
Message-Id: <9507242115.AA23182@bb29c.mdd.comm.mot.com>
To: debian-bugs@pixar.com, iwj10@cus.cam.ac.uk
Subject: Re: Bug#1151: bash exit status incorrect - seriously affects dpkg upgrade

This is a sidebar issue.

iwj10@cus.cam.ac.uk (Ian Jackson) said:

> Package: bash
> Version: 1.14.4-1
> 
> chiark:~/junk> cat t
> #!/bin/sh -
> trap "true" 0
> exit 1
> chiark:~/junk> ./t
> chiark:~/junk> echo $?
> 0
> chiark:~/junk>
> 
> According to the manpage entry for `exit' it causes the shell to exit
> with the status specified; it is only supposed to use that of the last
> command executed if no status is specified (and even then IMO it [...]

This does appear to be a bash bug, in that this version of bash is not
behaving as its man page says it does, nor as some earlier bash versions
behaved.

However, the "#!/bin/sh" line in the script bothers me, in that that it
presumes that this /bin/sh is bash.

I did the following experiment:

    bb29c /h/bb/mitchell/x> sh -x x
    + trap true 0 
    + exit 1 
    + true 
    bb29c /h/bb/mitchell/x> echo $?
    0
    bb29c /h/bb/mitchell/x> uname -a
    SunOS bb29c 4.1.3 1 sun4c

The sh(1) man page on this SunOS sytem says:

  DESCRIPTION
       sh, the Bourne shell, is the  standard  UNIX-system  command
       interpreter.  It executes commands read from a terminal or a
       file.

On this system, which claims to offer a standard Bourne shell, we see
results which differ from the desired (and advertised) results from
bash when executing this script.

I don't know what the Posix standard may or may not have to say about
this, but it looks as if we may be expecting bash-man-page-specific
behavior from /bin/sh.  Are we justified in assuming that /bin/sh
will be bash?

Message received at debian-bugs:

From cus.cam.ac.uk!iwj10 Mon Jul 24 08:24:12 1995
Return-Path: <iwj10@cus.cam.ac.uk>
Received: from pixar.com by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0saPMa-00063SC; Mon, 24 Jul 95 08:24 PDT
Received: from bootes.cus.cam.ac.uk by pixar.com with SMTP id AA11352
  (5.67b/IDA-1.5 for debian-bugs-pipe@mongo.pixar.com); Mon, 24 Jul 1995 08:22:14 -0700
Received: by bootes.cus.cam.ac.uk 
	(Smail-3.1.29.0 #36) id m0saOhx-000C0MC; Mon, 24 Jul 95 15:42 BST
Received: by chiark
	id <m0saO0I-0002YNZ@chiark.al.cl.cam.ac.uk>
	(Debian /\oo/\ Smail3.1.29.1 #29.32); Mon, 24 Jul 95 14:57 BST
Message-Id: <m0saO0I-0002YNZ@chiark.al.cl.cam.ac.uk>
Date: Mon, 24 Jul 95 14:57 BST
From: iwj10@cus.cam.ac.uk (Ian Jackson)
To: Debian bugs submission address <debian-bugs@pixar.com>
Subject: bash exit status incorrect - seriously affects dpkg upgrade

Package: bash
Version: 1.14.4-1

chiark:~/junk> cat t
#!/bin/sh -
trap "true" 0
exit 1
chiark:~/junk> ./t
chiark:~/junk> echo $?
0
chiark:~/junk> 

According to the manpage entry for `exit' it causes the shell to exit
with the status specified; it is only supposed to use that of the last
command executed if no status is specified (and even then IMO it
should return the status of the last command executed *before* the
exit call).

ksh (pdksh 5.1.3-1) gets this right.

This is a very serious problem, because it can cause scripts which
encounter errors to return non-zero status incorrectly.

An example of this is in the new C dpkg: the preinst script sometimes
prompts the user, asking whether they want to continue the upgrade
despite certain problems (which the user is warned about).  With bash
1.14.4-1 (and dpkg 0.93.62) the installation proceeds even if the user
says `no' !

The behaviour here has, I think, changed recently.  When I wrote the
new C dpkg preinst script I was probably using bash 1.13 or some such,
and it worked correctly.

I shall see if I can find a workaround.  However, in the meantime,
could we please withdraw bash 1.14.4-1 and revert to an earlier
version with more but hopefully less serious bugs.

In the meantime potential alpha testers may wish to wait with
installing the new C dpkg if they have bash 1.14.4-1 installed.

Thanks to Bill Mitchell for spotting the problem.

Ian.