Surprising behaviour when reading from a named pipe and standard input
Earnestly <[email protected]> Tue, 10 Feb 2026 01:11:11 +0000
| Newsgroups | org.kernel.vger.dash |
|---|---|
| Message-ID | <aYqFr-Twb-njdsDh@teapot> |
I came across this behavioural difference between dash and sh(bash),
bash and zsh.
When attempting to read from a named pipe and stdin at the same time in
a backgrounded process I appear to be losing stdin:
#!/bin/dash --
f() {
mkfifo pipe
cat pipe - <&0 &
echo hello > pipe
rm -f pipe
wait
}
echo hi | f
This outputs (busybox sh likewise):
hello
With sh(bash), bash and zsh I get (and expect):
hello
hi
At first I thought it might be a difference in how dash implements
set -m due to how jobs without it set have their stdin opened as
/dev/null but adding set -m does not appear to help.
Can you help me understand what is happening and why dash differs?
---
I would like to use this technique with age to read identities from a
pipe as the tool doesn't offer another way, read code below:
decrypt() {
# XXX https://github.com/FiloSottile/age/discussions/685
tmpdir=${TMPDIR:-/tmp}/curator-$$
pipe=$tmpdir/s
defer rm -rf -- "$tmpdir"
nofail mkdir -m 0700 -- "$tmpdir"
# XXX Using a pipe limits the size of the identity to around 1MiB on Linux.
# cf. /proc/sys/fs/pipe-max-size
nofail mkfifo -m 0600 -- "$pipe"
# nb. stdin needs to be specified as without job control (set -m) the
# command will have its stdin set to /dev/null.
age -i "$pipe" -d <&0 &
exec 9>"$pipe"
rm -f -- "$pipe"
key_request private >&9
exec 9>&-
wait
}