Re: bug#26371: [PATCH 0/1] tty: do not provide conflicting information

[Christian Brauner]

On Wed, Apr 05, 2017 at 02:27:12PM -0700, Paul Eggert wrote:
> On 04/05/2017 01:17 PM, Christian Brauner wrote:
> > Oh, where can that information be gathered from? I looked up isatty() and
> > ttyname{_r}() in:
> > 
> > The Open Group Base Specifications Issue 7
> > IEEE Std 1003.1-2008, 2016 Edition
> > Copyright © 2001-2016 The IEEE and The Open Group
> > 
> > but couldn't find any such requirement
> I inferred it from the similar wording used for both functions. isatty
> "shall return 1 if fildes is associated with a terminal", and ttyname "shall
> return a pointer to a string containing a null-terminated pathname of the
> terminal associated with file descriptor fildes". Although in theory POSIX
> allows either function to fail with a weird error number whenever it
> pleases, clearly the intent is that the two functions be consistent, many
> programs assume that they are consistent, and any implementation where
> isatty succeeds but ttyname fails is an implementation that is asking for
> trouble.

Maybe, but it doesn't sound obvious to me especially in the presence of e.g.
mount namespaces on Linux. But this isn't even platform specific! If you somehow
mask the device path (overmounting or think of any other reason) the file
descriptor refers to then ttyname{_r}() _will fail to retrieve it_. I don't know
if most platforms will even set an errno in this case and so your patch will
likely be just another version of reporting misleading information. If errno is
not set then now instead of reporting "not a tty" but exiting with success you
will now report ./tty: standard input: Success! but exit with an error.

> 
> > Form a purely technical perspective it just seems to make a lot more sense 
> > to
> > exit with success if the file descriptor actually refers to a terminal. The 
> > name
> > of the device it refers to just seems syntactical sugar.
> That's what 'tty -s' does. Perhaps if we were designing things from scratch,
> 'tty' would behave like 'tty -s'. But longstanding practice is for 'tty'
> (without arguments) to output the terminal's name, and programs expect that
> behavior.
> 
> Really, the underlying platform should get fixed. In the meantime I suppose

Maybe, but it's not really an explicit POSIX requirement according to what I've
gathered from the above paragraph. For glibc, Serge and I have taken care that
errno is set to ENODEV in this case which seemed to everyone involved in this
discussion to be the most natural way of handling this scenario.

> that the best plain 'tty' can do is report the configuration error and exit.
> 
> Did you try the patch I installed? That is, does ttyname have a reasonable
> errno value when it returns NULL on your platform?

Yes, as I said at least for glibc you'd get:

root@zest1:~/dummy/coreutils/src# ./tty
./tty: standard input: No such device

Which is not necessarily an improvement since the fd _is_ actually a tty.

Thanks for hearing me rant! :)
Christian