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
    }