Re: non-interactive set -m

[Eric Blake <ebb9@xxxxxxx>]

Peter Stephenson <pws <at> csr.com> writes:

> Part of my reason for suggesting that is the following.  It's true you
> can't change the MONITOR option after the shell starts.  It's probably
> fixable, but being able to switch back and forth might be complicated
> (though I haven't looked in detail).

POSIX requires that 'set -m'/'set -o monitor' be switchable on the fly, without
regards to whether the shell is interactive.  And your claim that MONITOR
cannot be changed on the fly is false: zsh already handles this for interactive
shells, with knock-on effects that fg and bg change behavior depending on the
current state of MONITOR (also as specified by POSIX).

$ ARGV0=sh zsh -ci 'echo $-; set +m; sleep 1& fg; echo $-; set -m; echo $-'
569XZim
zsh:fg:1: no job control in this shell.
569XZi
569XZim

>  However, making MONITOR work at
> startup isn't so hard: the following simple patch stops it being tied to
> interactive mode.  As this has no effect unless you request MONITOR, it
> won't cause problems elsewhere.  This would mean that
> 
>   ARGV0=sh zsh -mc '...'
> 
> will enable monitor mode at startup.

Unfortunately, for autoconf's purposes, that is not possible without
contortions of re-starting a script if it is detected that zsh is running the
script but not in sh mode.  Autoconf does not have control over how the user
started a script, but wants the shell to be in POSIX mode after the point that
the script is already started, as part of sanitizing the environment to be
portable across as many shells as possible, so autoconf is forced to use
'emulate sh' (although we may switch it to use 'emulate -R sh', based on your
advice).

>  Note that you do need a tty or pty
> of some sort (that's what SHTTY != -1 is testing), but that's probably
> obvious from the way job control works.

You are correct that you can't change interactive mode on the fly - whether $-
prints i is fixed from the moment the shell starts up.  You are also correct
that the initial state of MONITOR depends on whether the shell is interactive,
and that whether a shell is interactive depends, in part, on whether there is a
tty: POSIX requires that interactive shells start with 'set -m' and
non-interactive shells start with 'set +m' unless specified differently by
other command line options, so at startup, $- will usually contain either both
or neither of 'im'.  But while the presence of a tty is a factor for
determining whether the shell is interactive, it is NOT a factor in determining
whether job control works.  Job control works just fine without a tty, as
proved by bash and ksh.  Meanwhile, the presence of a tty is not the ONLY way
to get an interactive shell; POSIX requires that even without a tty, a shell
started with an explicit -i must be interactive (although in this condition,
the shell need not print prompts).

According to POSIX, job control does two things - it changes messages printed
before a prompt (related to interactivity and the presence of a tty), and it
makes it possible to spawn asynchronous processes in separate process groups
for independent tracking.  It is the latter part (separate process groups) that
autoconf wants to use to enable parallel testsuites, and which is unrelated to
whether there is a tty.  And in a non-interactive shell, the former part
(printing a message before prompts) does not matter, since non-interactive
shells never print prompts in the first place.

Basically, zsh cannot be used for parallel autoconf tests unless you fix the
bug of allowing job control support to be changed on the fly for non-interactive
shells.

-- 
Eric Blake