[Top][All Lists]

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

Re: [PATCH v3 2/2] Use O_IGNORE_CTTY where appropriate

From: Sergey Bugaev
Subject: Re: [PATCH v3 2/2] Use O_IGNORE_CTTY where appropriate
Date: Tue, 13 Jun 2023 13:54:32 +0300


On Sun, Jun 11, 2023 at 7:54 AM Paul Eggert <eggert@cs.ucla.edu> wrote:
> OK, I'm starting to see the distinction now.

So you did misunderstand it! That means not only is the explanation in
the glibc manual (reproduced below) unclear, but my previous attempts
to describe it and its differences to O_NOCTTY were unclear as well.

"Do not recognize the named file as the controlling terminal, even if
it refers to the process’s existing controlling terminal device.
Operations on the new file descriptor will never induce job control

This is an opportunity to improve the docs! -- please tell me how we
could improve it so it would have been clear to you from the start.
And in any case I should add a blurb about it making open faster and a
recommendation to use it whenever possible.

> > I don't know whether any programs actually care about this ctty
> > feature. Presumably users care? -- as I understand it, this is
> > intended to be used with job control in the shell
> If so, it's a well-kept secret, as Bash doesn't use O_IGNORE_CTTY.

There seems to be a miscommunication here as well: I'm replying to
your question of whether anybody cares about O_IGNORE_CTTY behavior
*not* being the default, i.e. the default behavior being the opposite
(honoring ctty). Programs don't actively use O_IGNORE_CTTY to get that
behavior exactly because they get that behavior by default. So you
can't get an estimate for whether any software cares by grepping it

The "this" in my "this is intended to be used with job control in the
shell" refers to the feature of cttys that a background process trying
to do I/O on the terminal results in a signal (and then an error if
the signal is ignored); and not to O_IGNORE_CTTY (which turns this
feature *off*).

> The only program I know of that uses O_IGNORE_CTTY is Emacs, and it's
> for what appears to be relatively minor optimization when it is opening
> a file that is a tty. On non-Hurd platforms Emacs instead uses setsid to
> remove the controlling tty entirely (since the notion of controlling
> terminal doesn't mix well with how Emacs operates).

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.


reply via email to

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