Keith MARSHALL <keith.marshall@xxxxxxxxx> writes: > David Fang wrote: >> 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. Whether /dev/std{in,out,err} are devices, symlinks, or even present is going to be system dependent. They're real character devices on NetBSD: $ ls -l /dev/std{in,out,err} crw-rw-rw- 1 root wheel 22, 2 Feb 19 11:01 /dev/stderr crw-rw-rw- 1 root wheel 22, 0 Feb 19 11:01 /dev/stdin crw-rw-rw- 1 root wheel 22, 1 Feb 19 11:01 /dev/stdout And while they're symlinks on Solaris, they're not to /proc: $ ls -l /dev/std{in,out,err} lrwxrwxrwx 1 root root 6 Nov 21 09:15 /dev/stderr -> ./fd/2 lrwxrwxrwx 1 root root 6 Nov 21 09:15 /dev/stdin -> ./fd/0 lrwxrwxrwx 1 root root 6 Nov 21 09:15 /dev/stdout -> ./fd/1 >> 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. It depends on why David is checking for them. For example, one reason you might want to is to ensure a program works with /dev/std{in,out,err} when specified as a command line argument as an input/output filename even if the OS does not have native support for /dev/std{in,out,err}. I know I've seen this somewhere, but I can't recall where off hand. --jtc -- J.T. Conklin _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf