NetBSD Problem Report #46327

From www@NetBSD.org  Thu Apr 12 22:07:01 2012
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
	by www.NetBSD.org (Postfix) with ESMTP id A333363BBEC
	for <gnats-bugs@gnats.NetBSD.org>; Thu, 12 Apr 2012 22:07:01 +0000 (UTC)
Message-Id: <20120412220701.0EE0C63B9FE@www.NetBSD.org>
Date: Thu, 12 Apr 2012 22:07:01 +0000 (UTC)
From: dmandelb@bbn.com
Reply-To: dmandelb@bbn.com
To: gnats-bugs@NetBSD.org
Subject: sh background commands have old return value
X-Send-Pr-Version: www-1.0

>Number:         46327
>Category:       bin
>Synopsis:       sh background commands have old return value
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    bin-bug-people
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Apr 12 22:10:00 +0000 2012
>Closed-Date:    Tue Apr 05 08:51:02 +0000 2016
>Last-Modified:  Tue Apr 05 08:51:02 +0000 2016
>Originator:     David Mandelberg
>Release:        
>Organization:
>Environment:
NetBSD [redacted] 5.99.63 NetBSD 5.99.63 (GENERIC) #2: Fri Feb  3 04:53:44 EST 2012  [redacted]/netbsd-current/obj/sys/arch/i386/compile/GENERIC i386
>Description:
/bin/sh doesn't set $? properly when running a command in the background. It should set $? to 0 if the command can be run, but instead it leaves $? unchanged from the return value of the last command. This especially problematic in this case:

#!/bin/sh -e
if false; then
  :
else
  true & # aborts the script
fi
>How-To-Repeat:
# true; true & echo $?
0
# false; true & echo $?
1

>Fix:

>Release-Note:

>Audit-Trail:
From: Jukka Ruohonen <jruohonen@iki.fi>
To: gnats-bugs@NetBSD.org
Cc: gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org
Subject: Re: bin/46327: sh background commands have old return value
Date: Fri, 13 Apr 2012 08:47:21 +0300

 On Thu, Apr 12, 2012 at 10:10:01PM +0000, dmandelb@bbn.com wrote:
 > # true; true & echo $?
 > 0
 > # false; true & echo $?
 > 1

 This does not seem to occur with '-c':

 $ /bin/sh -c "true; true & echo $?"  
 0
 $ /bin/sh -c "false; true & echo $?"
 0

From: "Jukka Ruohonen" <jruoho@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/46327 CVS commit: src/tests/bin/sh
Date: Fri, 13 Apr 2012 06:12:32 +0000

 Module Name:	src
 Committed By:	jruoho
 Date:		Fri Apr 13 06:12:32 UTC 2012

 Modified Files:
 	src/tests/bin/sh: t_exit.sh

 Log Message:
 Although this does not fail, add a case for the discussion in PR bin/46327.


 To generate a diff of this commit:
 cvs rdiff -u -r1.2 -r1.3 src/tests/bin/sh/t_exit.sh

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: Robert Elz <kre@munnari.OZ.AU>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: bin/46327 (sh background commands have old return value)
Date: Sun, 21 Feb 2016 13:59:41 +0700

 I have been looking at the sh tests, and came across the test
 which was added due to this PR, which caused me to look at the
 PR (open sh PRs are of interest right now...)

 Since it is years ago, for the benefit of those reading this
 on the list, I will summarise the issue:

 	true; true & echo $?
 	0
 correct
 	false; true & echo $?
 	1
 incorrect - $? should come from the "true &" not from the preceding "false"
 (ksh (/bin/ksh on NetBSD), bash, and zsh, at least, all get this correct.)

 A reply to the PR states ...

 	This does not seem to occur with '-c':

 but that's incorrect, it does ...

 	sh -c 'false; true & echo $?'
 	1

 the PR response (incorrectly) used ...

 	/bin/sh -c "false; true & echo $?"

 which (of course) expands $? from the calling shell, and results in
 running
 	/bin/sh -c "false; true & echo 0"
 from which it is no surprise that it prints "0" ...

 To compound matters, even though ...

 	Although this does not fail, add a case for the discussion
         in PR bin/46327.

 was done, adding an ATF test that should have detected the bug, the
 test added was ...

         atf_check -s exit:0 -o ignore -e ignore -x "false; true & echo $?"

 which checks that the exit value from "echo" is 0 (isn't it always?) and
 otherwise ignores the output which because of the incorrect quoting, would
 not detect the error anyway.   The atf-check man page does
 warn about use of -x because of quoting issues, but this one (and
 the incorrect result test) is about as simple as it gets!

 I think it should be something like

 	atf_check -o match:0 -e empty -x 'false; true & echo $?'

 (and the same for the preceding "true; true &" test, though that one
 is not expected to fail either way).

 I will add this bug as one to look for (and hopefully fix) in the
 sh sources (the bug is still there in sh from current), but perhaps someone
 else can fix the test (someone who understands atf better than I, and
 can fix it the best way.)   For now it probably also needs an atf_expect_fail.

 For now, I am running the tests (src/tests/bin/sh/t_exit.sh) with
 this in the code ...

 background_body() {
         atf_check -o match:0 -e empty -x 'true; true & echo $?'
         atf_expect_fail "PR bin/46327"
         atf_check -o match:0 -e empty -x 'false; true & echo $?'
 }

 and it appears to be doing as expected.

 kre

From: "Christos Zoulas" <christos@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/46327 CVS commit: src/bin/sh
Date: Wed, 24 Feb 2016 09:57:12 -0500

 Module Name:	src
 Committed By:	christos
 Date:		Wed Feb 24 14:57:12 UTC 2016

 Modified Files:
 	src/bin/sh: eval.c

 Log Message:
 PR/46327: David Mandelberg: Fix exit codes of background jobs (from kre)


 To generate a diff of this commit:
 cvs rdiff -u -r1.112 -r1.113 src/bin/sh/eval.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

State-Changed-From-To: open->closed
State-Changed-By: wiz@NetBSD.org
State-Changed-When: Tue, 05 Apr 2016 08:51:02 +0000
State-Changed-Why:
Fixed in -current, thanks!


>Unformatted:

Home	PR Database Search