On 6/22/20 5:51 PM, Godmar Back wrote:
> You are correct that they then preserve the state upon exit.
> I wasn't aware of that, but it makes a lot of sense - otherwise, "stty
> sane" wouldn't work, or even be necessary (not necessary if the shell
> always restored the state it had upon startup.) Out of curiosity, is
> this a POSIX requirement or an established convention? I can't find
> it in the POSIX standard quickly.
I assume it's a convention. Bash has done it for forever.
>>> I first noticed this when students in my class's shell project failed
>>> to properly implement terminal handling, but programs such vi/vim
>>> still continued to work even when stopped and later placed back in the
>>> foreground. I discovered that these programs implement a SIGCONT
>>> handler where they restore their terminal state when continued, but I
>>> wrote this off as an attempt to be robust in the presence of buggy
>>> shells.
>>
>> This is how programs that modify terminal settings, like editors or
>> more/less pagers, do things. It's standard behavior.
>
> Obviously, if the shells most users use don't implement the POSIX
> standard, these programs have to compensate.
I'm not sure that's the reason. It's more likely that no historical
shells ever implemented this behavior, and the standard way to write
programs that manipulated the terminal settings was to manage them
yourself. You either caught SIGTSTP and did the restore/reset tty
stuff from the signal handler or you mapped the functionality to a
keystroke and did the same thing from a function where you sent
yourself SIGSTOP.
Editors and other programs have been `compensating' in this way since
before there was POSIX. Look at the 4.3 BSD source for `more' or `vi',
for example.
>
> Thank you for your reply. Could you share any insights why bash
> doesn't follow POSIX in this regard, like zsh, but unlike ksh, tcsh,
> and dash/ash?
ksh93u+ 2012-08-01 on RHEL 7 does do this.
tcsh isn't a POSIX shell, so I admit I don't pay attention to it.
I got curious, so I looked at what dash does -- a system call trace looks
like it seems to `succeed' because it doesn't save or restore the terminal
settings at all (dash-0.5.10.2). That presumably holds true for other ash-
based shells, but I didn't check. It does leave them susceptible to
programs that don't clean up the terminal when they're suspended or
terminate abnormally.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/
