Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Mark Hatle <mark.hatle@windriver.com>
To: <openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 1/6] runqemu: Use OE_TMPDIR
Date: Mon, 14 May 2012 17:34:41 -0500	[thread overview]
Message-ID: <4FB18881.80702@windriver.com> (raw)
In-Reply-To: <20120508020738.46574fa5@wrlaptop>

On 5/8/12 2:07 AM, Peter Seebach wrote:
> 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".)

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




  reply	other threads:[~2012-05-14 22:44 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-03 17:12 [PATCH 1/6] runqemu: Use OE_TMPDIR Bernhard Reutner-Fischer
2012-05-03 17:12 ` [PATCH 2/6] runqemu: use modern, single-char name of test(1) Bernhard Reutner-Fischer
2012-05-07 23:25   ` Joshua Lock
2012-05-15 19:59     ` Bernhard Reutner-Fischer
2012-05-15 20:58       ` Khem Raj
2012-05-15 22:03       ` Peter Seebach
2012-05-03 17:12 ` [PATCH 3/6] runqemu: simplify process_filename() Bernhard Reutner-Fischer
2012-05-03 17:12 ` [PATCH 4/6] runqemu: add and use error() Bernhard Reutner-Fischer
2012-05-03 17:12 ` [PATCH 5/6] runqemu: minor tweaks Bernhard Reutner-Fischer
2012-05-03 17:12 ` [PATCH 6/6] runqemu: be sh neutral Bernhard Reutner-Fischer
2012-05-04 21:18 ` [PATCH 1/6] runqemu: Use OE_TMPDIR Scott Garman
2012-05-07 23:56 ` Scott Garman
2012-05-08  7:07   ` Peter Seebach
2012-05-14 22:34     ` Mark Hatle [this message]
2012-05-14 22:40       ` Khem Raj
2012-05-14 22:51   ` Marko Lindqvist
2012-05-14 23:15     ` Mark Hatle

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=4FB18881.80702@windriver.com \
    --to=mark.hatle@windriver.com \
    --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