public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Sergey Bugaev <bugaevc@gmail.com>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: libc-alpha@sourceware.org, bug-hurd@gnu.org,
	 Samuel Thibault <samuel.thibault@gnu.org>
Subject: Re: [PATCH v3 2/2] Use O_IGNORE_CTTY where appropriate
Date: Tue, 13 Jun 2023 13:54:32 +0300	[thread overview]
Message-ID: <CAN9u=Hfnh_635v8zt7adBt0jRnfMHYpiSPhuVfhY5NMrqoMFmg@mail.gmail.com> (raw)
In-Reply-To: <3033f0f6-58a3-0e38-b1fd-7edd6a730310@cs.ucla.edu>

Hello,

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

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

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.

Sergey

  reply	other threads:[~2023-06-13 10:54 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-04 20:42 [PATCH v3 0/2] O_IGNORE_CTTY everywhere Sergey Bugaev
2023-06-04 20:42 ` [PATCH v3 1/2] include/fcntl.h: Define O_IGNORE_CTTY Sergey Bugaev
2023-06-05 18:24   ` Adhemerval Zanella Netto
2023-06-09  9:29     ` Sergey Bugaev
2023-06-12 18:56       ` Adhemerval Zanella Netto
2023-06-13  9:42         ` Sergey Bugaev
2023-06-13 13:06           ` Adhemerval Zanella Netto
2023-06-04 20:42 ` [PATCH v3 2/2] Use O_IGNORE_CTTY where appropriate Sergey Bugaev
2023-06-05  9:28   ` Florian Weimer
2023-06-05 11:55     ` Sergey Bugaev
2023-06-05 20:58   ` Paul Eggert
2023-06-06  9:21     ` Sergey Bugaev
2023-06-09 18:37       ` Paul Eggert
2023-06-09 21:13         ` Sergey Bugaev
2023-06-09 21:35           ` Paul Eggert
2023-06-10 16:13             ` Sergey Bugaev
2023-06-11  4:54               ` Paul Eggert
2023-06-13 10:54                 ` Sergey Bugaev [this message]
2023-06-14  5:40                   ` Paul Eggert
2023-06-16 16:26                     ` Sergey Bugaev
2023-06-17 20:22                       ` Paul Eggert
2023-06-18 21:55           ` Samuel Thibault
2023-06-19  8:57             ` Sergey Bugaev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAN9u=Hfnh_635v8zt7adBt0jRnfMHYpiSPhuVfhY5NMrqoMFmg@mail.gmail.com' \
    --to=bugaevc@gmail.com \
    --cc=bug-hurd@gnu.org \
    --cc=eggert@cs.ucla.edu \
    --cc=libc-alpha@sourceware.org \
    --cc=samuel.thibault@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).