Re: proper bash configure behavior when /dev/stdin is present, /dev/{,self/}fd are not?

[Chet Ramey]

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    chet@case.edu    http://tiswww.cwru.edu/~chet/