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>