From: Phil Blundell <philb@gnu.org>
To: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 1/1] oe-init-build-env, scripts/oe-buildenv-internal: add error detecting for $BDIR
Date: Wed, 03 Aug 2011 15:25:16 +0100 [thread overview]
Message-ID: <1312381517.4325.83.camel@phil-desktop> (raw)
In-Reply-To: <201108031521.07596.paul.eggleton@linux.intel.com>
On Wed, 2011-08-03 at 15:21 +0100, Paul Eggleton wrote:
> On Wednesday 03 August 2011 15:11:07 Phil Blundell wrote:
> > Has anybody ever tried to quantify how much work would be involved in
> > making OE work within the constraints of POSIX sh (i.e. work with dash)?
> > It does seem fairly obnoxious/embarrassing that you're obliged to
> > make /bin/sh be bash on a systemwide basis; I can't think offhand of any
> > other piece of software I use that has this kind of requirement.
>
> Would that not entail fixing everything we build that contains shell scripts
> with bashisms that claim "#!/bin/sh"?
Yes, but anything that builds on current Ubuntu (etc) will presumably be
OK in that respect, and any shell scripts which are installed on the
target ought to be getting fixed anyway since bash is unlikely to be
available there. If you assume that those two groups of things are
going to have to be solved anyway (by someone) then it isn't obvious to
me that the remaining problem set will be all that large.
If it were to become a real issue then one could write a class which
searched for shell scripts inside ${S} and reprocessed them to use
#!/bin/bash, or alternatively write an LD_PRELOAD sort of shim to detect
such scripts at exec() time and redirect them to bash rather than sh.
p.
next prev parent reply other threads:[~2011-08-03 14:29 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-02 6:08 [PATCH 0/1] fix to bug 671 Dexuan Cui
2011-08-02 6:08 ` [PATCH 1/1] oe-init-build-env, scripts/oe-buildenv-internal: add error detecting for $BDIR Dexuan Cui
2011-08-02 11:43 ` Richard Purdie
2011-08-03 4:06 ` Darren Hart
2011-08-03 6:46 ` Cui, Dexuan
2011-08-03 13:50 ` Darren Hart
2011-08-03 14:01 ` Paul Eggleton
2011-08-03 14:11 ` Phil Blundell
2011-08-03 14:21 ` Paul Eggleton
2011-08-03 14:25 ` Phil Blundell [this message]
2011-08-04 2:25 ` Cui, Dexuan
2011-08-04 6:00 ` Darren Hart
2011-08-04 7:37 ` Cui, Dexuan
2011-08-04 13:44 ` Darren Hart
2011-08-04 14:49 ` Cui, Dexuan
2011-08-04 14:53 ` Phil Blundell
2011-08-04 15:14 ` Cui, Dexuan
2011-08-09 2:13 ` Cui, Dexuan
2011-08-09 4:35 ` Darren Hart
2011-08-09 14:04 ` Cui, Dexuan
2011-08-09 15:06 ` Darren Hart
2011-08-10 3:18 ` Cui, Dexuan
2011-08-10 12:21 ` Richard Purdie
2011-08-10 13:04 ` Richard Purdie
2011-08-04 12:07 ` Richard Purdie
2011-08-04 13:37 ` Darren Hart
2011-08-04 14:19 ` Richard Purdie
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=1312381517.4325.83.camel@phil-desktop \
--to=philb@gnu.org \
--cc=openembedded-core@lists.openembedded.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