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

[Godmar Back]

On Mon, Jun 22, 2020 at 6:28 PM Chet Ramey <chet.ramey@case.edu> wrote:
>
> >
> > 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.

You're correct, and actually, your observation applies to tcsh as
well. If I stty the change before resuming, it will not restore the
previous state.

I checked the CVS web of 4.3 BSD and it seems that early versions of
vi/more couldn't rely on it since the shell didn't do it - for
instance, Bill Joy's 4.3 BSD csh.c didn't do it.

Going back in history, let me quote a bit more; it seems that the
POSIX writers were acknowledging 4.2 BSD as an influence:

--
While the job control facilities supplied by POSIX.1 can, in theory,
support different types of interactive job control interfaces supplied
by different types of shells, there was historically one particular
interface that was most common when the standard was originally
developed (provided by BSD C Shell). This discussion describes that
interface as a means of illustrating how the POSIX.1 job control
facilities can be used.
--

they also refer to csh as an influence by writing "(For example, from
the C Shell, the user can execute the command, csh &.)" which refers
to how a shell should behave if it doesn't have control of its
controlling terminal upon startup, and later write
--
The intent in adding 4.2 BSD-style job control functionality was to
adopt the necessary 4.2 BSD programmatic interface with only minimal
changes to resolve syntactic or semantic conflicts with System V or to
close recognized security holes.
--

Lastly, here's a quote that makes me think that it was their intent to
allow applications to run under job control even if those applications
changed terminal settings and were job control unaware:

---
Implementing Job Control Applications

Most applications do not need to be aware of job control signals and
operations; the intuitively correct behavior happens by default.
--

In any event, this was very illuminating - though I have one last
question: why did you not implement it?

Were you unaware of what POSIX asks you to do, or did you consciously
decide against implementing it (perhaps because, apparently, there
is/was never an apparent need to do so?)

 - Godmar