From slaven.rezic@berlin.de  Sun Feb 10 16:25:43 2002
Return-Path: <slaven.rezic@berlin.de>
Received: from mailoutvl21.berlin.de (mail.berlin.de [195.243.105.33])
	by hub.freebsd.org (Postfix) with ESMTP id B246A37B402
	for <FreeBSD-gnats-submit@freebsd.org>; Sun, 10 Feb 2002 16:25:42 -0800 (PST)
Received: from herceg.de ([213.7.62.104]) by mailoutvl21.berlin.de
          (InterMail vK.4.03.05.00 201-232-132 license c0e4b842f1eddc5308d584e55543c802)
          with ESMTP id <20020211002736.JKUF27460.mailoutvl21@herceg.de>
          for <FreeBSD-gnats-submit@freebsd.org>;
          Mon, 11 Feb 2002 01:27:36 +0100
Received: (from eserte@localhost)
	by vran.herceg.de (8.11.4/8.9.3) id g1B09XF29027;
	Mon, 11 Feb 2002 01:09:33 +0100 (CET)
	(envelope-from eserte)
Message-Id: <200202110009.g1B09XF29027@vran.herceg.de>
Date: Mon, 11 Feb 2002 01:09:33 +0100 (CET)
From: Slaven Rezic <eserte@vran.herceg.de>
Reply-To: Slaven Rezic <slaven.rezic@berlin.de>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: sh: "jobs" is not pipeable
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         34811
>Category:       bin
>Synopsis:       sh(1) "jobs" is not pipeable
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    jilles
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Feb 10 16:30:01 PST 2002
>Closed-Date:    
>Last-Modified:  Fri Jan 28 11:00:21 UTC 2011
>Originator:     Slaven Rezic
>Release:        FreeBSD 4.3-STABLE i386
>Organization:
www.rezic.de
>Environment:
System: FreeBSD vran.herceg.de 4.3-STABLE FreeBSD 4.3-STABLE #6: Mon Jul 9 11:49:47 CEST 2001 root@vran.herceg.de:/vran/home/src/FreeBSD-4/src/sys/compile/VRAN i386


	
>Description:
	
	The output of /bin/sh's "jobs" builtin cannot be sent to a
	pipe.

>How-To-Repeat:
	
	Start a process in a sh in the background.
	Type:

		jobs | grep .

	There is no output. But:

		jobs > /tmp/foo

	will output the jobs into /tmp/foo.

>Fix:

	
>Release-Note:
>Audit-Trail:

From: Martin.Kaeske@stud.tu-ilmenau.de
To: freebsd-gnats-submit@FreeBSD.org, slaven.rezic@berlin.de
Cc:  
Subject: Re: bin/34811: sh: "jobs" is not pipeable
Date: 14 Feb 2002 12:18:18 -0000

 I can't say I understood /usr/src/bin/sh completely, but it seems
 that sh forks a new shell if it detects a pipe "|". This new shell
 is responsible for evaluating the pipe, that means 
 "jobs|grep" creates a new shell and jobs is executed within
 the new shell and not in root-shell. I don't know wether such
 behaviour is intended or not.
 What disturbs me is the following (from sh(1)):
   Shell builtin commands are the exception to this rule. They are
   executed in the current shell,...
 Does "current shell" mean the root-shell? If that's correct I think
 sh doesn't behave as documented in sh(1).
 
 If its really a bug can someone tell me what the expected behaviour is?
 Maybe I can fix it. Or is such treatment of pipes required by any
 standard (maybe posix-1003.2)?.
 
 Martin

From: <kerochan2@gmail.com>
To: <freebsd-gnats-submit@FreeBSD.org>
Cc:  
Subject: Re: bin/34811: sh: "jobs" is not pipeable
Date: Sat,  2 Oct 2004 02:53:31 +0000 (GMT)

 The standard behaviour is this:
 
    faber $ (sleep 10 & jobs | cat)
    [1]+  Running                 sleep 10 &
    faber $ (sleep 10 & jobs | grep '.')
    [1]+  Running                 sleep 10 &
 
 Commands inside () are forced into a subshell;
 sleep 10 is then started in the background;
 jobs is a shell builtin, but it's output must still be pipable;
 AND IT IS!
 
 Does the sequence "(sleep 10 & jobs | cat)" produce output at you?
 [It should.]

From: Jilles Tjoelker <jilles@stack.nl>
To: bug-followup@FreeBSD.org, slaven.rezic@berlin.de,
	Martin.Kaeske@stud.tu-ilmenau.de, kerochan2@gmail.com
Cc:  
Subject: Re: bin/34811: sh(1) "jobs" is not pipeable
Date: Fri, 3 Apr 2009 21:34:18 +0200

 The way I read POSIX, I think this does not have to work. Commands in a
 pipeline with two or more commands may or may not be executed in a
 subshell (this 'or' applies to each of the commands individually), and a
 subshell has its own list of unwaited jobs.
 
 Accordingly,  (jobs)  gives empty output (in /bin/sh as well as bash4).
 bash4 seems to do special trickery with the jobs command in pipelines
 (as permitted): even in commands like  jobs >`tty` | jobs  both give
 proper output. This, however, breaks down if you make it more
 complicated such as by replacing  jobs  with  { jobs; }.
 
 On the other hand, $(jobs) works in both /bin/sh and bash4, although
 POSIX says that command substitution happens in a subshell. However,
 POSIX also mentions $(jobs -p) in an informative section, and it seems
 useful.
 
 If you want to add this feature, evalpipe() in eval.c would probably be
 the place. It would be quite specific to very few builtin commands which
 tend not to be used much in scripts. (Note that slow operations in the
 main shell process cannot be ^Z'ed, and that builtin commands may be
 overridden with functions.)
 
 -- 
 Jilles Tjoelker
Responsible-Changed-From-To: freebsd-bugs->jilles 
Responsible-Changed-By: remko 
Responsible-Changed-When: Fri Jan 28 08:23:41 UTC 2011 
Responsible-Changed-Why:  
Hi Jilles, can you have a look at the PR and close it or do whatever is 
needed with it? Thanks! 

http://www.freebsd.org/cgi/query-pr.cgi?pr=34811 

From: Jilles Tjoelker <jilles@stack.nl>
To: bug-followup@FreeBSD.org, slaven.rezic@berlin.de
Cc:  
Subject: Re: bin/34811: sh(1) "jobs" is not pipeable
Date: Fri, 28 Jan 2011 11:59:10 +0100

 > [request to allow jobs | ...]
 
 This could be allowed in a way similar to optimized command
 substitution. If here-documents were expanded in the main shell
 environment, something like
 
 grep foo <<EOF
 $(jobs)
 EOF
 
 would perform the requested function of
 
 jobs | grep foo
 
 This change to here-documents may not be made but suggests a way to
 implement this in the code.
 
 Apart from jobs, the change may also be useful to improve performance
 with echo and printf, saving a fork in constructions like
 
 x=$(echo "$x" | sed -e 's/#/%/')
 
 That would need some care to preserve NUL bytes and final newlines in
 echo/printf output.
 
 Various other caveats are in my followup of 3 Apr 2009.
 
 In any case, I consider this low priority as POSIX does not require it
 to work and you can work around it by placing jobs in a command
 substitution.
 
 -- 
 Jilles Tjoelker
>Unformatted:
