Hi,
On 13/05/16 04:06, Geoff Nixon wrote:
> Let me start with a couple of corrections to that previous thread.
>
>
> 1. The line: jobs -p > /tmp/pids # this works
>
> Does *not*, in fact, work. Meaning there is *no* instance in which it
works.
This should work just fine. Do you have a short test script where it
does not work for you?
> But they do not. The present behavior is to simply dump the process
IDs directly
> to the TTY, it seems. Which is not, at all, what the specification
dictates.
That's not what happens. While there are a lot of contexts where you can
reasonably argue that jobs -p should output PIDs to stdout and where
dash doesn't, when it doesn't, it doesn't output anything. It doesn't
somehow start dumping PIDs elsewhere.
> In review, a subshell inherits a duplicate of the parent environment,
which
> includes the asynchronous list of background tasks, and the shell
environment is
> *explicitly* not to be changed, unless otherwise specified. Which it
is not.
This is the main point of your message, and it's reasonable, but it's
not clearly right or clearly wrong. ksh and mksh agree with your
interpretation. bash comes across as inconsistent (but there may be a
logic that's simply not immediately obvious). dash disagrees with your
interpretation, and zsh appears to disagree as well.
sleep 1 &
echo $(jobs -p)
(jobs -p)
jobs -p
ksh and mksh print the PID thrice.
bash prints the PID twice, it omits it in (jobs -p).
dash prints the PID once.
zsh is a bit unclear since its -p option has a more limited effect, but
appears to work like dash, only printing one (non-empty) line of output.
Your logic relies on the list of jobs being a property of the
environment. That's a reasonable interpretation, but not the only one.
Another interpretation is the environment that started a job being a
property of the job. In that interpretation, that information is not
part of the environment and hence not copied when duplicating the
environment. And it wouldn't be the first time that the "Application
Usage" section of a utility contradicts the normative requirements.
That said, it does seem extremely likely that trivial examples such as
echo $(jobs -p)
are intended to work the way you expect, regardless of whether the
standard manages to state the requirements correctly. Other cases are
not so clear, not when looking at the standard, and also not when
looking at what other shells do. This makes it difficult to come up with
a complete fix.
Personally, I feel that even if your interpretation is wrong (and I'm
not saying it is), it is still less undesirable than dash's current
behaviour. If there's a reasonable chance a patch for it would be
accepted, I'd be willing to try to make it so.
Cheers,
Harald van Dijk
--
To unsubscribe from this list: send the line "unsubscribe dash" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
