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