On 3/28/18 5:59 PM, Brian Carnes wrote: > When configuring bash on a self-hosted QNX 6.6 or QNX7 system: > > This is an OS that has /dev/stdin and friends, but does not have /dev/fd. > > When blind cross-compiling bash for QNX, one would get a guess answer of: > bash_cv_dev_fd=standard > bash_cv_dev_stdin=present > > When doing the safer self-hosted native configure, we get several > significant improvements, but also: > bash_cv_dev_fd=absent > bash_cv_dev_stdin=absent > > When "the truth" for QNX should really be (we think): > bash_cv_dev_fd=absent > bash_cv_dev_stdin=present > > The odd configure output is due to the test having the presence of > /dev/stdin guarded by testing for the existence of /dev/fd or /dev/self/fd: > > if *test -d /dev/fd* && (exec test -r /dev/stdin < /dev/null) ; then > bash_cv_dev_stdin=present > elif *test -d /proc/self/fd* && (exec test -r /dev/stdin < /dev/null) ; > then > bash_cv_dev_stdin=present > else > bash_cv_dev_stdin=absent > fi
This test dates from 1999. It's quite possible that the assumptions valid at that time are no longer so, like every implementation of /dev/stdin making it a symlink to /dev/fd/0. > At first glance it appears that: > lib/sh/eaccess.c > redir.c To emulate the filenames with consistent semantics on systems that can't be guaranteed to provide it. > So, can those in the know weigh in on which interpretation below is correct: None of these is relevant unless you want /dev/stdin treated as different from file descriptor 0 in some way. If your semantics for /dev/stdin differ (e.g., if a stat on /dev/stdin returns something different from an fstat on file descriptor 0), then the distinction matters. Is there something special that happens, say, when you open /dev/stdin that is different from dup'ing file descriptor 0? Unless you have special semantics, I don't think it matters. > > (a) The DEV_STDIN code block isn't relevant unless you're in the presence > of DEV_FD, so it's harmless and appropriate to have the current configure > output. > > (b) The dependency is there for good reason, and we're missing what will > break in the presence of DEV_FD=no + DEV_STDIN=yes I recall an old system (FreeBSD maybe?) that made /dev/fd a loadable file system, shipped with /dev/stdin a symlink to /dev/fd/0, and could get itself in a state that testing /dev/stdin would pause until someone (auto-?) mounted /dev/fd. It's been 19 years. > (d) The DEV_FD -> DEV_STDIN dependency should be removed from the test > completely, as a patch for all environments? I'd be ok with this one as long as it doesn't cause problems. Can anyone think of a system in common use today where it would? Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/