On Fri, Apr 27, 2018 at 05:23:36PM +0000, 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 </dev/tty& sleep 1; stty' speed 38400 baud; line = 0; intr = ^G; -brkint -imaxbel iutf8 --- Perhaps it was implied that async commands are in the foreground (as far as the system is concerned) when job control is disabled, but that is misleading. A proposed minimal fix: > 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
