[PATCH v3 2/2] Use O_IGNORE_CTTY where appropriate

[Paul Eggert]

On 2023-06-16 09:26, Sergey Bugaev wrote:
> Hello,

> 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

"In case the named file is statically known not to" ->
"If the named file cannot"

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

Replace this with just "@code{O_IGNORE_CTTY} improves performance on the 
Hurd." as the rest is redundant.


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

Fine, so add an O_KEEP_CTTY flag for programs like sudo that want to 
play tricks with /dev/tty, and add a feature-test macro like 
_DEFAULT_IGNORE_CTTY to let applications choose whether O_IGNORE_CTTY or 
O_KEEP_CTTY is the default. If done right this would be an upward 
compatible API and ABI change, and would let people fix their apps with 
a simple '#define _DEFAULT_IGNORE_CTTY 1' before their other #include 
directives, instead of wandering through all their source code looking 
for places to add O_IGNORE_CTTY here and there.


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

Haven't a clue. Why don't you try it and run it for a while? But better 
yet, let's change the API as described above, and then try that with Emacs.