Re: tty state not restored after restarted stopped job
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
Re: tty state not restored after restarted stopped job
On Sat, Mar 31, 2018 at 09:36:23PM +, Thorsten Glaser wrote: > Hi, > > I sometimes have weird tty state even after a process finished; > this is mostly mpg123 running in foreground, so no backgrounding > involved. When I then press Enter, the tty is back to normal > state; is that true for your scenario too? Typing ENTER does not change anything in my case. But the tty is not in an unforeseen state: it is just that after the command finishes (successfully) if it has changed the tty state, this state is recorded (and not reset to the value before it started) only if the job has not been stopped, which I found susrprising. I wondered if mksh records the stopping explicitely or if it is just a side-effect of the code that does not keep the tty state after a failed command (ends with non zero status or killed by SIGQUIT etc.). > I didnb t find the underlying issue yet. If anyone can jump in > with more debugging, or perhaps patches, Ib d be glad. First one should know what is the correct behaviour. The feature of discarding tty changes after a failed command is related to job control but it is not documented and not standard as neither bash nor ksh do the same. What makes sense is to discard the tty state after a killed command as bash and ksh do. After a failed command I don't think it is necessary but it can be considered a safe choice. Before a patch fixing the strange case of a "successful but temporarily stopped job has failed" it would be good to document the feature (and the bug, if it is one). PS. bash has the same "bug", which can be tested with the following command to circumvent the lack of tty state restoration when restarting a job: ``` $ sh -c 'stty; sleep 2; stty; stty intr ^G; stty' $ stty intr ^C; stty; sh -c 'stty intr ^G; sleep 2; stty; stty intr ^G; stty' speed 38400 baud; line = 0; -brkint -imaxbel iutf8 ^Z [1]+ Stopped sh -c 'stty intr ^G; sleep 2; stty; stty intr ^G; stty' $ fg; stty sh -c 'stty intr ^G; sleep 2; stty; stty intr ^G; stty' speed 38400 baud; line = 0; -brkint -imaxbel iutf8 speed 38400 baud; line = 0; intr = ^G; -brkint -imaxbel iutf8 speed 38400 baud; line = 0; -brkint -imaxbel iutf8 ```
tty state not restored after restarted stopped job
In the first case, the command modifies the tty state and the state is kept for the following commands. In the second case, the command that modifies the tty state is interrupted, then when restarted the tty state is restored for it but when it finishes the tty state is reset to the default again, which is not consistent with the first case. Is this a bug as I think it is? ``` 1 $ stty intr ^C; stty; sh -c 'stty intr ^G; sleep 2; stty'; stty speed 38400 baud; line = 0; -brkint -imaxbel iutf8 speed 38400 baud; line = 0; intr = ^G; -brkint -imaxbel iutf8 speed 38400 baud; line = 0; intr = ^G; -brkint -imaxbel iutf8 ``` ``` 2 $ stty intr ^C; stty; sh -c 'stty intr ^G; sleep 2; stty'; stty speed 38400 baud; line = 0; -brkint -imaxbel iutf8 ^Zspeed 38400 baud; line = 0; -brkint -imaxbel iutf8 [1] + Stopped \sh -c "stty intr ^G; sleep 2; stty" $ fg; stty \sh -c "stty intr ^G; sleep 2; stty" speed 38400 baud; line = 0; intr = ^G; -brkint -imaxbel iutf8 speed 38400 baud; line = 0; -brkint -imaxbel iutf8 ``` PS. ksh saves the tty state when a job is stopped, restored it when it is restarted, and keeps the modified state when the job finishes. bash resets a default when a job is stopped but does not save the tty state it seems.
