On Fri, Apr 27, 2018 at 05:23:36PM +, Thorsten Glaser wrote:
> From looking at the code, I donb t think it entirely correct.
> Thereb 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 itb s probably merely incomplete
> (or in the Job control subsection?).
>
> *looks* b and the state of the terminal is saved or restored when a
>foreground job is stopped or restarted, respectivelyb
> it saysb & perhaps we should reword this slightly?
>
>
> Ib 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?
It surprised me that even when job control is disabled, only a
"foreground" (as viewed by the shell) job can change the terminal state.
If the job does not get its own process group, how come it can't modify
the terminal state?
The following shows that a "background" command can change the terminal
state (since stdin is redirected to /dev/null for background commands,
either pass "-f /dev/tty" to stty or redirect stdin):
---
$ stty intr ^C; mksh -c 'stty intr ^G 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
+ cuted in the foreground when job control is enabled or by any command
+ when job control is disabled, 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.
--
G.raud