All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.