Date: Fri, 3 Apr 2009 19:40:04 GMT From: Jilles Tjoelker <jilles@stack.nl> To: freebsd-bugs@FreeBSD.org Subject: Re: bin/34811: sh(1) "jobs" is not pipeable Message-ID: <200904031940.n33Je4Gx098757@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/34811; it has been noted by GNATS.
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200904031940.n33Je4Gx098757>