[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
proper bash configure behavior when /dev/stdin is present, /dev/{,self/}
From: |
Brian Carnes |
Subject: |
proper bash configure behavior when /dev/stdin is present, /dev/{,self/}fd are not? |
Date: |
Wed, 28 Mar 2018 18:36:12 -0700 |
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
At first glance it appears that:
lib/sh/eaccess.c
redir.c
are the only consumers of HAVE_DEV_STDIN, and that the code so guarded
would function in the absence of HAVE_DEV_FD.
So, can those in the know weigh in on which interpretation below is correct:
(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
(c) There is some other pathological environment where bash wants the
DEV_STDIN code disabled when DEV_FD isn't there, and we should refine this
test in our patch to further distinguish QNX from the environment that
created the test w/ DEV_FD to DEV_STDIN dependency.
(d) The DEV_FD -> DEV_STDIN dependency should be removed from the test
completely, as a patch for all environments?
Thanks!
P.S. For completeness:
# uname -a
QNX localhost 6.6.0 2014/02/22-18:29:34EST x86pc x86
# bash -version
GNU bash, version 4.3.48(1)-release (i486-pc-nto-qnx6.6.0)
# uname -a
QNX localhost 7.0.0 2017/02/14-16:01:20EST x86pc x86_64
# bash -version
GNU bash, version 4.3.48(1)-release (x86_64-pc-nto-qnx7.0.0)