Skip site navigation (1)Skip section navigation (2) 
Date:      Wed,  3 Apr 2002 00:16:38 +0200 (CEST)
From:      Matthias Buelow <mkb@altair.mukappabeta.net>
To:        FreeBSD-gnats-submit@FreeBSD.org
Subject:   bin/36671: /bin/sh problems with grouped pipe and output redir
Message-ID:  <20020402221638.640312C5@altair.mukappabeta.net>
next in thread | raw e-mail | index | archive | help 

>Number:         36671
>Category:       bin
>Synopsis:       /bin/sh problems with grouped pipe and output redir
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Apr 02 14:20:02 PST 2002
>Closed-Date:
>Last-Modified:
>Originator:     Matthias Buelow
>Release:        FreeBSD 4.5-20020326-STABLE i386
>Organization:
>Environment:
System: FreeBSD altair.mukappabeta.net 4.5-20020326-STABLE FreeBSD 4.5-20020326-STABLE #2: Sun Mar 31 18:23:50 CEST 2002 root@altair.mukappabeta.net:/usr2/src/sys/compile/ALTAIR i386


>Description:

	FreeBSD's /bin/sh implementation's got a problem with regard
	to lists which contain pipes and I/O redirection that applies
	to the entire list.

	Please look at the following examples:

	First an ordinary grouped list with just one command:

	$ { :; }
	$ jobs
	$

	and with stdout/err redirected:

	$ { :; } >/dev/null 2>&1
	$ jobs
	$

	now with a pipe instead of a single command:

	$ { :|:; }
	$ jobs
	$

	so far everything ok as expected.  Now with redirection, it
	messes up:

	$  { :|:; } >/dev/null 2>&1
	$ jobs
	[1] 1473 Exit 2               :
	    1474 Exit 2               :
	$ 

	This should not happen; the shell should not print any background
	jobs (there must not be any, since the list is executed synchronously
	and not even in a subshell.)

	That wouldn't be so annoying if not, when used in the context of
	my .profile script (I use /bin/sh for root), it would cause premature
	end of parsing of said script, resulting in about half of the script
	not being run at all.  I've isolated a test example, which shows a
	sample premature abort of script parsing (when run in the context of
	the current shell at least, like it is done with sh reading .profile):


	cmdinpath()
	{
		{ type "$1"|grep '/'; } >/dev/null 2>&1
	}
	if cmdinpath less
	then PAGER=less
	else PAGER=more
	fi
	echo PAGER is $PAGER
	

	store into a file "t" and type the following:

	$ set -o xtrace		# doesn't change results, only shows
				# what the shell is doing
	$ . ./t
	+ . ./t
	+ cmdinpath less	# stops at "if cmdinpath less"...
	$ echo $?		# doesn't even get to the final echo
	+ echo 2
	2
	$ jobs
	[1] 1542 Exit 2               type ${1}
	    1543 Exit 2               grep /
	$

	For comparison, in Korn shell, the script executes properly:

	$ ksh93
	+ ksh93
	$ . ./t
	PAGER is less
	$ jobs
	$

	It also works as expected in the SystemV Bourne shell, ksh88
	and pdksh.  NetBSD's (1.5.1) /bin/sh, which is also the 4.4BSD
	ash-derived sh has the same problem.
	

>How-To-Repeat:

	See above.
>Fix:

	None yet; I'll perhaps have a look into it.


>Release-Note:
>Audit-Trail:
>Unformatted:

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?20020402221638.640312C5>