bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Does bash save/restore terminal settings as required by POSIX job co


From: Godmar Back
Subject: Re: Does bash save/restore terminal settings as required by POSIX job control?
Date: Mon, 22 Jun 2020 17:51:30 -0400

On Mon, Jun 22, 2020 at 5:19 PM Chet Ramey <chet.ramey@case.edu> wrote:
>
> On 6/22/20 4:48 PM, Godmar Back wrote:
> > (Disclosure: I performed a search for terminal, terminal settings,
> > tcsetattr in the bash-bug mailing list, without finding a discussion.
> > My apologies if this is a known issue or was already discussed.)
> >
> > Hi,
> >
> > according to POSIX Part A, Base Definitions (line 726-728, pg 20, Part
> > A: Base Definitions-IEEE and The Open Group.), a job control shell has
> > the following responsibility:
> >
> > "When a foreground (not background) job stops, the shell must sample
> > and remember the current terminal settings so that it can restore them
> > later when it continues the stopped job in the foreground (via the
> > tcgetattr( ) and tcsetattr( ) functions)."
> >
> > Does bash implement this functionality?  If implemented correctly, I
> > would expect the program appended below to not fail its assertions.
>
> Nobody does this.

Nobody may be a bit too strong of a statement, though, the version of
ksh on CentOS8 does do it, as it passes my test;
please observe:

$ ksh
$ stty -a
... eof = ^D ...
$ ./ts_test
This job should now stop, please run 'fg' to continue it
[1] + Stopped                  ./ts_test
$ stty -a
.... eof = ^D; ...
$ fg %1
./ts_test
Job now continuing...
$ stty -a
... eof = ^E ....
$

and also tcsh 6.20.00 I have installed on an Ubuntu 18 box:

$ tcsh
optiplex:~/tmp> ./ts_test
This job should now stop, please run 'fg' to continue it

Suspended
optiplex:~/tmp> jobs
[1]  + Suspended                     ./ts_test
optiplex:~/tmp> fg %1
./ts_test
Job now continuing...
optiplex:~/tmp> stty -a
... eof = ^E ...

and also 'ash' (not sure which version)

$ ash
$ ./ts_test
This job should now stop, please run 'fg' to continue it
[1] + Stopped                    ./ts_test
$ fg %1
./ts_test
Job now continuing...
$ stty -a
... eof = ^E;
$

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 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.

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?
I'm genuinely curious.

 - Godmar



reply via email to

[Prev in Thread] Current Thread [Next in Thread]