Hi again,
>Thinking a bit more about this, I found a valid reason not to keep the
>terminal state after a restarted job exits (successfully): the tty
>state in which that job was started can be obsolete at the time it is
>restarted because the tty state may have been modified while the job was
>stopped (or running in the background).
good thinking.
>It would be a rare case where mksh is more "advanced" than ksh if the
>behaviour is intentional.
This is all from pdksh/oksh, so… ;-)
>I join a patch that adds a manage subsection "Terminal state" explaining
>how to change the terminal state and describing the exception for
>temporarily stopped jobs (and mentioning that the line editing
>code saves/restores the terminal state too). The saving/restoring of
>the tty state for stopped/restarted jobs is already documented in the
>subsection "Job control".
From looking at the code, I don’t think it entirely correct.
There’s a tty_hasstate, and one of the comments around it says
/*
* Only restore tty settings if job was originally
* started in the foreground. Problems can be
* caused by things like 'more foobar &' which will
* typically get and save the shell's vi/emacs tty
* settings before setting up the tty for itself;
* when more exits, it restores the 'original'
* settings, and things go down hill from there...
*/
although, slightly below, it also says
/*-
* Don't use tty mode if job is stopped and
* later restarted and exits. Consider
* the sequence:
* vi foo (stopped)
* ...
* stty something
* ...
* fg (vi; ZZ)
* mode should be that of the stty, not what
* was before the vi started.
*/
which matches your description, so it’s probably merely incomplete
(or in the Job control subsection?).
*looks* “and the state of the terminal is saved or restored when a
foreground job is stopped or restarted, respectively”
it says… perhaps we should reword this slightly?
I’ve now moved the new subsection *below* the one on job control and
removed the tty stuff from the job control one, to have it all in one
place. The wording is currently like this:
Terminal state
The state of the controlling terminal can be modified by a command exe-
cuted in the foreground, whether or not job control is enabled, but the
modified terminal state is only kept past the job's lifetime and used for
later command invocations if the command exits successfully (i.e. with an
exit status of 0). When such a job is momentarily stopped or restarted,
the terminal state is saved and restored, respectively, but it will not
be kept afterwards. In interactive mode, when line editing is enabled,
the terminal state is saved before being reconfigured by the shell for
the line editor, then restored before running a command.
I think this matches our understanding of the code; if not, please feel
free to enter further comments into this discussion. The same goes for
what the code actually does; with it being documented like this, are you
happy with it?
Thanks,
//mirabilos (still ill at home, but decided to tackle some TODO items)
--
Yay for having to rewrite other people's Bash scripts because bash
suddenly stopped supporting the bash extensions they make use of
-- Tonnerre Lombard in #nosec
