From: "Jörg Krause" <joerg.krause@embedded.rocks>
To: buildroot@busybox.net
Subject: [Buildroot] bash: /dev/fd/62: No such file or directory
Date: Wed, 21 Mar 2018 16:25:03 +0100 [thread overview]
Message-ID: <1521645903.17352.2.camel@embedded.rocks> (raw)
In-Reply-To: <874llggl14.fsf@dell.be.48ers.dk>
Hi Peter,
On Fri, 2018-03-16 at 15:19 +0100, Peter Korsgaard wrote:
> > > > > > "J?rg" == J?rg Krause <joerg.krause@embedded.rocks> writes:
>
> > Hi,
> > I am facing an issue with busybox init system, bash and mdev. When
> a
> > bash script uses process substitution, bash ends with an error:
>
> > """
> > # bash -c 'read x< <(echo 1); echo $x'
> > bash: /dev/fd/62: No such file or directory
> > """
>
> > The issue is addressed is some threads, e.g. [1]. The problem is
> that
> > /dev/fd does not exist when using mdev:
>
> So that is really strictly seen a bug in bash. The /dev/fd
> convenience
> symlink is afaik a convention from udev/systemd.
>
> But OK, bash might not be alone and the pragmatic solution would
> indeed
> be to create these symlinks ourselves in the busybox and sysvinit
> inittabs, similar to how we create /dev/pts and /dev/shm.
>
> It is only really needed if (e)udev isn't used, but it doesn't really
> hurt to create them even if eudev will recreate them afterwards.
>
> Keep in mind that we still support a static /dev, so we should also
> add
> them to system/device_table_dev.txt and redirect errors to /dev/null
> so
> you don't get a bunch of warnings about these symlinks when booting
> with
> a static /dev.
>
> Notice that it isn't only about /dev/fd. From
> eudev-3.2.5/src/shared/dev-setup.c:
>
> static const char symlinks[] =
> "-/proc/kcore\0" "/dev/core\0"
> "/proc/self/fd\0" "/dev/fd\0"
> "/proc/self/fd/0\0" "/dev/stdin\0"
> "/proc/self/fd/1\0" "/dev/stdout\0"
> "/proc/self/fd/2\0" "/dev/stderr\0";
>
> There is some logic to only create /dev/core if /proc/kcore exists,
> but
> I think we can just create it unconditionally.
Thanks for looking into this!
> Care to send patches doing this?
Yes, I can do that.
J?rg
next prev parent reply other threads:[~2018-03-21 15:25 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-15 22:55 [Buildroot] bash: /dev/fd/62: No such file or directory Jörg Krause
2018-03-16 14:19 ` Peter Korsgaard
2018-03-21 15:25 ` Jörg Krause [this message]
2018-03-29 19:46 ` Jörg Krause
2018-03-30 11:11 ` Peter Korsgaard
2018-03-30 11:51 ` Jörg Krause
2018-03-30 12:41 ` Peter Korsgaard
2018-04-01 9:45 ` Jörg Krause
2018-04-01 10:27 ` Peter Korsgaard
2018-04-04 18:12 ` Jörg Krause
2018-04-04 18:58 ` Peter Korsgaard
2018-04-04 20:22 ` Jörg Krause
2018-04-04 20:23 ` Peter Korsgaard
2018-04-04 20:39 ` Jörg Krause
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=1521645903.17352.2.camel@embedded.rocks \
--to=joerg.krause@embedded.rocks \
--cc=buildroot@busybox.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.