On Mon, 7 May 2012 16:56:11 -0700 Scott Garman <scott.a.gar...@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. _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
