On 5/8/12 2:07 AM, Peter Seebach wrote:
On Mon, 7 May 2012 16:56:11 -0700
Scott Garman<[email protected]> 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".)
It's actually worse then =~ is a bashism, it's a specific version of bash. I'm
using bash as my shell, and it simply doesn't work my system.
The following works for me:
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -300,14 +300,16 @@ findimage() {
# recently created one is the one we most likely want to boot.
filenames=`ls -t $where/*-image*$machine.$extension 2>/dev/null | xargs`
for name in $filenames; do
- if [ "$name" =~ core-image-sato-sdk -o \
- "$name" =~ core-image-sato -o \
- "$name" =~ core-image-lsb -o \
- "$name" =~ core-image-basic -o \
- "$name" =~ core-image-minimal ]; then
+ case $name in
+ *core-image-sato-sdk* | \
+ *core-image-sato* | \
+ *core-image-lsb* | \
+ *core-image-basic* | \
+ *core-image-minimal*)
ROOTFS=$name
return
- fi
+ ;;
+ esac
done
echo "Couldn't find a $machine rootfs image in $where."
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.
I agree, besides the =~ doesn't work at all of me..
[mhatle@msp-mhatle-lx2 build-ia32-4]$ bash --version
GNU bash, version 4.1.7(1)-release (x86_64-redhat-linux-gnu)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
that is on FC-13. (ya, I know it's old.. but it's intentional we support older
machines.)
--Mark
-s
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
