Surprising behaviour when reading from a named pipe and standard input

Earnestly
2026-02-10T01:11:14Z

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
}