public inbox for dash@vger.kernel.org
 help / color / mirror / Atom feed
From: Earnestly <zibeon@gmail.com>
To: dash@vger.kernel.org
Subject: Surprising behaviour when reading from a named pipe and standard input
Date: Tue, 10 Feb 2026 01:11:11 +0000	[thread overview]
Message-ID: <aYqFr-Twb-njdsDh@teapot> (raw)

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
    }

             reply	other threads:[~2026-02-10  1:11 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-10  1:11 Earnestly [this message]
2026-02-10  2:00 ` Surprising behaviour when reading from a named pipe and standard input Harald van Dijk
2026-02-10 10:24   ` Earnestly

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aYqFr-Twb-njdsDh@teapot \
    --to=zibeon@gmail.com \
    --cc=dash@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox