Re: AC_CHECK_FILES on /dev/stdin

[David Fang]

> > I naively tried to use AC_CHECK_FILE(S) on /dev/stdin /dev/stdout
> > and /dev/stderr to detect their presence, but the test result is
> > 'no' for these 'files'.
>
> These are not real devices.  You may find entries in /dev, which
> suggest otherwise, but look closely:  if they exist at all, they
> will be symbolic links to fd entities in the /proc pseudo-file
> system; i.e. they aren't connected to real files or devices, but
> exist as virtual properties of processes.

Hi,
        Thanks for the excellent answer.

> > The result is 'yes', however, for /dev/null.
>
> This, OTOH, is a real device, in the sense that the kernel manages
> it with a device driver which simply returns EOF on read, or discards
> all data written.
>
> > Is there a more appropriate test for the presence of these special
> > files?  or do I need to roll my own macro-test using something like
> > "test -f"?  (Or am I checking for something that should/need not be
> > checked?)  Suggestions?
>
> You don't need to check for them.  Unless you explicitly force it to
> be otherwise, *every* process is *guaranteed* to have stdin, stdout
> and stderr streams;  you must be doing something very esoteric, if
> you find a need to refer to /dev/stdin, /dev/stdout or /dev/stderr.

        To give a little more context for what I'm trying to do in C++
(experimentally): I've discovered that std::ifstream foo("/dev/stdin")
results in a file stream that works just like cin, likewise for stdout,
etc...  Just like in standard C, one could use stdin, stdout, stderr as
FILE*, I'd like to do the equivalent with std::fstream's.  (std::cin is a
basic_istream, not type-equivalent to a basic_ifstream.)  I'm writing a
little stream manager that maintains stream objects (not references to)
internally without any run-time polymorphism, so I need one single type to
handle both stdio and file streams, -without- using C FILE*'s.
        Basically, all I need to do is write a AC_TRY_RUN-style configure
test to make sure this works as expected, since this may seem unusual.
Does this sound reasonable?


David