public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Tobias Burnus <burnus@net-b.de>
To: Thomas Koenig <tkoenig@netcologne.de>
Cc: Jerry DeLisle <jvdelisle@verizon.net>,
	gfortran <fortran@gcc.gnu.org>,
	 gcc patches <gcc-patches@gcc.gnu.org>
Subject: Re: [patch, libfortran] PR44931 For INPUT_UNIT, INQUIRE NAME= should not return "stdin"
Date: Sun, 25 Jul 2010 09:39:00 -0000	[thread overview]
Message-ID: <4C4C0662.40001@net-b.de> (raw)
In-Reply-To: <1280049543.4506.3.camel@linux-fd1f.site>

Thomas Koenig wrote:
> Tobias Burnus wrote
>> Besides, I wonder whether using "" as string is better than using the
>> default std{in,out,err} in case ttyname fails. (This happens for
>> instance if the standard I/O redirected to a file or pipe.) 
>>     
> For Linux, we could return /proc/self/fd/1 for standard output (0 and 2
> correspondingly).  This appears to work, as this little program shows:
>   

Well, I think using /dev/std{in,out,err} is more portable than
/proc/self/fd/{0,1,2}. However, the question is whether those device
files are just common or truly ubiquitous on non-Windows GCC platforms;
I fear they are just common. I have checked the File Hierarchy Standard
it it does not specify anything under /dev/*. One could (on non-Windows)
of course check the existence of "/dev/std*" and if it does not exist
fall back to ttypname and if it also fails (or HAS_TTYNAME is not
defined) fall back to "". But the question is whether one should do so
much effort - most of the time one simply uses the units without
INQUIREing the filename - to (re)open the standard I/O streams.

(Side note: The 0,1,2 numbers are defined in POSIX; they are the values
of the unistd.h's symbolic constants STD{IN,OUT,ERR}_FILENO.)

Tobias

  reply	other threads:[~2010-07-25  9:39 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-25  0:56 Jerry DeLisle
2010-07-25  9:00 ` Tobias Burnus
2010-07-25  9:19   ` Thomas Koenig
2010-07-25  9:39     ` Tobias Burnus [this message]
2010-07-25 10:18       ` IainS
2010-07-25 15:31   ` Jerry DeLisle
2010-07-26 23:43     ` Dave Korn
2010-07-29 14:26 ` H.J. Lu

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=4C4C0662.40001@net-b.de \
    --to=burnus@net-b.de \
    --cc=fortran@gcc.gnu.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jvdelisle@verizon.net \
    --cc=tkoenig@netcologne.de \
    /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).