Re: The behavior of `jobs -p` is definitely, without a doubt, a bug

[Geoff Nixon <geoff@geoff.codes>]

---- On Wed, 18 May 2016 14:03:59 -0700 Harald van Dijk <harald@xxxxxxxxxxx> wrote ---- 
> 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? 

Sorry, you are absolutely right, this does *does* work. I could have sworn it
didn't when I tried before, but perhaps I was conflating it with something like
`jobs -p | tee /tmp/pids`, which doesn't work.

> > 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. 

Indeed, you are correct again; my mistake. Due to my incorrect conclusion
(that `jobs -p > /tmp/pids` fails), along with the fact that the
output of `jobs` fails in a pipeline, I drew the incorrect assumption that the
output of `jobs` *never* was sent to stdout. Apologies.

> > 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...

Yes, that is the core of my argument.

> .... 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. 

Oops! I somehow forgot to include the results of my tests with other
shells. You are correct, and in addition to what you mention above: pdksh, oksh,
and yash all also exhibit the "thrice" behavior, while busybox's ash
(at least my old 1.20.0 version) exhibits the same behavior as bash -- that is,
`(jobs -p)` does not work, but the others do.

I don't think zsh should be considered here, since it is explicitly
documented that `jobs -p` does something entirely different (process groups):
http://zsh.sourceforge.net/Doc/Release/Shell-Builtin-Commands.html

> 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.

While it's not really worth bickering about, I do in fact believe my
"interpretation" is *specified*. It's not on the `jobs` page, but in
"Shell Command Language", where it dictates that the environment includes:
" - Process IDs of the last commands in asynchronous lists known to this
shell environment".

> And it wouldn't be the first time that the "Application 
> Usage" section of a utility contradicts the normative requirements. 

True ;)

> 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.

Again, speaking for myself, I think the standard is actually pretty clear here.
Referring again to the "Shell Command Language" page:

    The format for grouping commands is as follows:
    (compound-list)
    Execute compound-list in a *subshell environment*...

That is, I believe the behavior of bash and busybox does not fully adhere to the
the standard; pdksh, ksh93, mksh, yash, and oksh are compliant.

> 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. 

Agreed. I'd very much like to see a patch for this; and I certainly hope it
would be accepted!

At the *very, very least*, I think the fact that `jobs -p` can have stdout
redirected to a file, yet cannot be used in a pipeline, is most definitely 
bug. Can you think of any other command where stdout can be redirected to a file
but cannot be piped?

I'd be willing to take a stab at a patch myself as well, but I'd much rather
leave this to more capable hands (someone more familiar with the dash codebase).
So I appreciate the offer!

Best,
Geoff

> 
> 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