> > 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
_______________________________________________
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
