coreutils
[Top][All Lists]
Advanced

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

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


From: Paul Eggert
Subject: Re: bug#26371: [PATCH 0/1] tty: do not provide conflicting information
Date: Wed, 5 Apr 2017 14:27:12 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0

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.

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



reply via email to

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