[OE-core] [PATCH 1/6] runqemu: Use OE_TMPDIR

[Peter Seebach]

On Mon, 7 May 2012 16:56:11 -0700
Scott Garman <scott.a.garman at 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
-- 
Listen, get this.  Nobody with a good compiler needs to be justified.