On 05/03/2012 10:12 AM, Bernhard Reutner-Fischer wrote:
> The error message erroneously talked about TMPDIR.> Just use OE_TMPDIR everywhere to make the name of the variable obvious.>> Signed-off-by: Bernhard Reutner-Fischer<rep.dot.nop@gmail.com>
Bernhard, these are great improvements - thanks for refactoring this!
Full series Acked-by: Scott Garman <scott.a.garman@intel.com>
Scott

On 05/03/2012 10:12 AM, Bernhard Reutner-Fischer wrote:
> The error message erroneously talked about TMPDIR.> Just use OE_TMPDIR everywhere to make the name of the variable obvious.>> Signed-off-by: Bernhard Reutner-Fischer<rep.dot.nop@gmail.com>
Bernhard,
This change wasn't well-tested and has broken the runqemu script for
both bash and dash. :(
From what I can tell, the =~ regex operator is a bashism. It's also one
that helps a lot with the code readability. So now that we're faced with
re-writing the script to avoid using that operator, I'm having second
thoughts about whether the runqemu script really needs to be
shell-agnostic. The alternative of invoking grep or other commands to
process the name patterns does not appeal to me.
I can understand why we're trying to ensure our build system doesn't
require /bin/sh to be bash, but I think support scripts like runqemu
might be a special case.
What do other people in the community think of this? The runqemu script
isn't trivial, and it has to run in a lot of different contexts. Should
we put the time in to make it shell-agnostic, or allow it to require bash?
Scott

On Mon, 7 May 2012 16:56:11 -0700
Scott Garman <scott.a.garman@intel.com> wrote:
> From what I can tell, the =~ regex operator is a bashism. It's also> one that helps a lot with the code readability. So now that we're> faced with re-writing the script to avoid using that operator, I'm> having second thoughts about whether the runqemu script really needs> to be shell-agnostic. The alternative of invoking grep or other> commands to process the name patterns does not appeal to me.> > I can understand why we're trying to ensure our build system doesn't > require /bin/sh to be bash, but I think support scripts like runqemu > might be a special case.> > What do other people in the community think of this? The runqemu> script isn't trivial, and it has to run in a lot of different> contexts. Should we put the time in to make it shell-agnostic, or> allow it to require bash?
Hmm. I am honestly not a big fan of the =~, simply because I almost
never remember it, and I can never think whether it's like perl's ~=
or Lua's ~=. (One is "matches", the other is "is not".)
I tend to write stuff like this as
case $name in
*pat1* | *pat2* | ... )
# code goes here
;;
esac
because that's the natural shell idiom. It can't do full regex
processing, but we really don't need that here; we just want an
unanchored pattern match. (And I'm not even sure we *want* a
fully-unanchored match.) I think the bash [[ ]] thing is one of the
kshisms, but "bash or ksh" is not much better. :P
From a maintenance standpoint, I like the case construct better
than [[]]. My interest in reading the bash man page to figure out what
some unfamiliar bit of punctuation means this week has declined over
the years.
-s

On 8 May 2012 02:56, Scott Garman <scott.a.garman@intel.com> wrote:
>> I can understand why we're trying to ensure our build system doesn't require> /bin/sh to be bash, but I think support scripts like runqemu might be a> special case.>> What do other people in the community think of this? The runqemu script> isn't trivial, and it has to run in a lot of different contexts. Should we> put the time in to make it shell-agnostic, or allow it to require bash?
1) Do not require /bin/sh to be bash
2) It's ok, and for "right tool for the job" -reasons often prefered,
to require that development machine has also bash installed.
So I'm happy with how runqemu currently has #!/bin/bash shebang. It
requires bash to be present, but not necessarily as /bin/sh
- ML

On 5/14/12 5:51 PM, Marko Lindqvist wrote:
> On 8 May 2012 02:56, Scott Garman<scott.a.garman@intel.com> wrote:>>>> I can understand why we're trying to ensure our build system doesn't require>> /bin/sh to be bash, but I think support scripts like runqemu might be a>> special case.>>>> What do other people in the community think of this? The runqemu script>> isn't trivial, and it has to run in a lot of different contexts. Should we>> put the time in to make it shell-agnostic, or allow it to require bash?>> 1) Do not require /bin/sh to be bash> 2) It's ok, and for "right tool for the job" -reasons often prefered,> to require that development machine has also bash installed.>> So I'm happy with how runqemu currently has #!/bin/bash shebang. It> requires bash to be present, but not necessarily as /bin/sh
I don't mind it using bash as long as it has bash-isms. Note, the recent =~
stuff didn't work on my machine, even with bash.
--Mark
>> - ML>> _______________________________________________> Openembedded-core mailing list> Openembedded-core@lists.openembedded.org> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core