On 12/12/25 6:59 PM, Robert Elz wrote:
Date: Fri, 12 Dec 2025 08:57:11 -0500 From: Chet Ramey <[email protected]> Message-ID: <[email protected]>| >> $ f=~/f; echo color: red > $f; foo=$( awk '/^color: / {print $2}' ~/f );set -x;cat | I'm leaning towards this explanation, since this only happens with gawk, | and not, for instance, /bin/echo. If bash were corrupting file descriptors, | it would be doing it for every external command. The latter I'd agree with, while not necessarily absolving bash of all blame - I'd like to know what happens on a fedora (or any other linux where the same occurs) when using dash, yash, or one of the ksh variants (or even zsh).
I built a quick Fedora 42 VM with gawk-5.3.1 (YES means that cat finds its
stdin and stdout are the same):
bash-devel: YES
dash: YES
ksh93: YES
mksh: NO
For bash, it doesn't matter whether or not readline is being used, so it's
not something that readline is doing to the file descriptor. It also
doesn't depend on whether bash is using $(...) or ${...} command
substitution.
If bash happened to be using the linux clone() sys call, instead of fork()
It's not, but glibc translates fork() into an (equvialent?) clone(2) call; the flags do not include CLONE_FILES. I briefly looked at strace output, and it doesn't look like any process in the set is executing a dup/dup3 call
So, perhaps using clone() might make for a cheaper fork() - but whatever is being shared must not be allowed (for semantic correctness) to affect the parent shell. If the file descriptor table were one of the things being shared, and the subshell were to do a freopen() as above, then the parent's stdin would be altered.
If this is the cause, it's glibc's fault.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU [email protected] http://tiswww.cwru.edu/~chet/
OpenPGP_signature.asc
Description: OpenPGP digital signature
