Hello,
On Wed, Jun 14, 2023 at 8:40 AM Paul Eggert <egg...@cs.ucla.edu> wrote:
> The first-quoted sentence is confusing and arguably wrong. If the named
> file is the process's existing controlling terminal, it will continue to
> be recognized as the controlling terminal.
Thanks, I can see how that can sound confusing: the *file* will
continue being recognized as the ctty, but the newly opened fd won't
be recognized as one that refers to a ctty.
> What's different is that I/O to the new fd won't induce SIGTTIN etc. So
> the second sentence is correct and the first is wrong. Perhaps the first
> sentence could be replaced by:
>
> "Cause operations on the new file descriptor to act as if the named file
> is not the process's controlling terminal, even if it is."
So how about this?
"Cause operations on the new file descriptor to act as if the named
file is not the process's controlling terminal, even if it is.
@xref{Job Control}.
When @code{O_IGNORE_CTTY} is not set, @code{open} has to perform a
runtime check for the named file being the process's controlling
terminal; setting @code{O_IGNORE_CTTY} allows @code{open} to skip this
check. In case the named file is statically known not to be the
process's controlling terminal, for example when opening a
configuration or a cache file using a well-known path, setting
@code{O_IGNORE_CTTY} will lead to improved @code{open} performance and
no behavior change. For this reason, it is good practice to always
set @code{O_IGNORE_CTTY} when opening files, unless there is a
possibility that the file being opened could be the process's
controlling terminal."
> Still, I still doubt many would care if O_IGNORE_CTTY
> became the default, particularly since O_NOCTTY is 0. What's the
> scenario whereby a Bash user would care, for example?
They would run a program/job in the background, and wouldn't want input
or output from the background program to mess up what they're doing.
With !O_IGNORE_CTTY, when the background program attempts to do I/O on
the terminal (only input by default, both with 'stty tostop'), its gets
stopped, and Bash reports:
[1]+ pid-here Stopped (tty input)
The user would then resume it with 'fg %' (or just '%') when they're
ready, and it would do its I/O then. This is described in "Unix Power
Tools" [0], the Bash manual [1], and Zsh guide [2], so it's not even
that obscure of a feature.
[0]: https://docstore.mik.ua/orelly/unix3/upt/ch23_09.htm
[1]: https://www.gnu.org/software/bash/manual/html_node/Job-Control-Basics.html
[2]: https://zsh.sourceforge.io/Guide/zshguide03.html#l39
Although O_IGNORE_CTTY would only matter if the program reopens the tty
explicitly, perhaps as /dev/tty or /dev/stdout, not for the file
descriptors inherited across exec. sudo does this (reopening the
terminal), for example, so if you have a 'sudo xxxx' line in a script
that you run as a background job, it'd steal your input if O_IGNORE_CTTY
behavior was the default.
> > Speaking of Emacs, and seeing that Emacs already defines O_IGNORE_CTTY
> > to 0 on non-Hurd, and that you're one of the Emacs maintainers (is
> > that right?): could perhaps Emacs benefit from using O_IGNORE_CTTY
> > more broadly too? I imagine loading all the .el files in ~/.emacs.d
> > involves way too many pointless ctty checks, for example.
>
> It might, I suppose. Got a patch?
Hmm, I see there's a emacs_open[at] wrapper that automatically adds
O_CLOEXEC (and also O_BINARY). So now I've got the same question for
you: does Emacs ever care about the default, !O_IGNORE_CTTY behavior?
Would anything break if I just make emacs_openat always add in
O_IGNORE_CTTY?
OT1H the answer surely must be no, since Emacs is an interactive
editor, it doesn't just read and write its stdin/stdout/stderr as
streams like classic Unix utilities do. OTOH I see that it does deal
with cttys and SIGTTOU in several places...
Sergey
