Re: non-interactive set -m

[Eric Blake <ebb9@xxxxxxx>]

Peter Stephenson <p.w.stephenson <at> ntlworld.com> writes:

> > It looks like the fg activated the sleep process, because it took five
> > seconds for the Stopped message to appear, but fg failed to print to stdout
> > the process that it just activated.
> 
> ... and the third part: this seems to be another question of testing if
> MONITOR is set (jobbing---I wish we didn't those #define's) but not if
> INTERACTIVE is set (interact).  Also need to fix up the output to go to
> stderr instead of the file (not) opened to the terminal.

POSIX states that fg output goes to stdout, not stderr.  Thus, I should have a
silent wait for 5 seconds with the following command; although with this latest
round of patches, things are still noisy:

$ Src/zsh -c 'set -m; sleep 5& fg >/dev/null'
[1] 5804
[1]  + running    sleep 5
$

It looks like two different sources of noise - creating the background task is
outputting information about the job just created, which should really be
conditional on being interactive (a non-interactive shell will use 'jobs' to
learn this information, rather than having it printed to stderr).  The other
source of noise is that fg is writing to stderr instead of the required stdout.

Also, POSIX states that fg output should be the name of the command that was
brought into the foreground, and not the 'jobs' output describing that command.

Notice how bash does it:
$ bash -ci 'set -m; sleep 5& fg >/dev/null'
[1] 21428
$ bash -c 'set -m; sleep 5& fg'
sleep 5
$ bash -c 'set -m; sleep 5& fg >/dev/null'
$

> I've done the same thing at another point, where the status of a job
> changes.  You're the guinea pig so if you think this output should or
> shouldn't be there I can leave it or change it.

Not a problem - I'm actually having fun trying to test this.  At any rate, given
my (lack of) familiarity with the zsh code layout, reporting my tests is easier
than trying to propose patches, although I'll do what I can.

-- 
Eric Blake