bug-hurd
[Top][All Lists]
Advanced

[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: Sat, 10 Jun 2023 19:13:58 +0300

Hello,

On Sat, Jun 10, 2023 at 12:36 AM Paul Eggert <eggert@cs.ucla.edu> wrote:
> > Do you perhaps mean that POSIX does not require a
> > newly opened terminal to become your ctty even if you don't pass
> > O_NOCTTY?
>
> Yes, that's right. The openat rationale mentions this topic.

do you mean this?:

"The O_NOCTTY flag was added to allow applications to avoid
unintentionally acquiring a controlling terminal as a side-effect of
opening a terminal file. This volume of POSIX.1-2017 does not specify
how a controlling terminal is acquired, but it allows an
implementation to provide this on open() if the O_NOCTTY flag is not
set and other conditions specified in XBD General Terminal Interface
are met."

That paragraph is indeed about O_NOCTTY and acquiring a ctty if you
don't yet have one. It says nothing about whether the O_IGNORE_CTTY
behavior is allowed. To reiterate: O_IGNORE_CTTY is not about
acquiring a ctty if you don't yet have one (that never happens
implicitly on the Hurd), but about (re)opening your current ctty.

> I don't see why anybody would care if the O_IGNORE_CTTY behavior became
> the default. And if nobody cares, let's just make it the default. That
> way, you won't have to change glibc, Gnulib, git, coreutils, etc.
>
> Do you have a scenario whereby making O_IGNORE_CTTY the default would
> break things? (It wouldn't break things as far as POSIX is concerned.)

But it would break things as far as POSIX is concerned: see the
description of how I/O on a ctty should behave (namely generating
SIGTTIN / SIGTTOU for a background process) in "11.1.4 Terminal Access
Control".

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, so you can launch
some long-running batch job in the background, and have it stopped
with SIGTTIN when it tries to read from your terminal (instead of it
fighting for input with whatever foreground job at the time); you can
then resume it and give it the desired input. Although this all (job
control as a whole) has largely faded away with the proliferation of
tabs in terminal emulators. But it still works, and is supposed to
work, on today's Unixes, and is required to work by POSIX.

Also I don't think it'd be possible to flip the default like that even
if we wanted to. O_IGNORE_CTTY is not some new feature, it's been in
glibc as far back as Git history goes ("initial import" in 1995 --
it's one of those many things about the Hurd that are older than me
:). This has been the behavior and a public API for 25+ years, we
cannot just change it to the opposite now.

Sergey



reply via email to

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