[PATCH] fdtget-runtest.sh: Fix failures when /bin/sh isn't bash

[PATCH] fdtget-runtest.sh: Fix failures when /bin/sh isn't bash

[Stephen Warren]

On Ubuntu, /bin/sh is dash (at least by default), and dash's echo doesn't
accept the -e option. This means that fdtget-runtest.sh's EXPECT file will
contain "-e foo" rather than just "foo", which causes a test failure.

To work around this, run /bin/echo instead of (builtin) echo, which has
more chance of supporting the -e option.

Another possible fix is to change all the #! lines to /bin/bash rather
than /bin/sh, and change run_tests.sh to invoke sub-scripts using $SHELL
instead of just "sh". However, that would require bash specifically, which
may not be desirable.

Signed-off-by: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
---
 tests/fdtget-runtest.sh |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/tests/fdtget-runtest.sh b/tests/fdtget-runtest.sh
index 982fbe1..c3a3559 100755
--- a/tests/fdtget-runtest.sh
+++ b/tests/fdtget-runtest.sh
@@ -8,7 +8,7 @@ rm -f $LOG $EXPECT
 trap "rm -f $LOG $EXPECT" 0
 
 expect="$1"
-echo -e $expect >$EXPECT
+/bin/echo -e $expect >$EXPECT
 shift
 
 verbose_run_log_check "$LOG" $VALGRIND $DTGET "$@"
-- 
1.7.5.4

Re: [PATCH] fdtget-runtest.sh: Fix failures when /bin/sh isn't bash

[David Gibson]

On Tue, Mar 20, 2012 at 08:23:46PM -0600, Stephen Warren wrote:
> On Ubuntu, /bin/sh is dash (at least by default), and dash's echo doesn't
> accept the -e option. This means that fdtget-runtest.sh's EXPECT file will
> contain "-e foo" rather than just "foo", which causes a test failure.
> 
> To work around this, run /bin/echo instead of (builtin) echo, which has
> more chance of supporting the -e option.
> 
> Another possible fix is to change all the #! lines to /bin/bash rather
> than /bin/sh, and change run_tests.sh to invoke sub-scripts using $SHELL
> instead of just "sh". However, that would require bash specifically, which
> may not be desirable.
> 
> Signed-off-by: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>

Acked-by: David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org>

Jon, please apply.

I don't think this fix is perfect - for example, I wonder what will
happen if /bin/echo is actually a busybox instance.  But it's
definitely better than right now, where the testsuite will give
failures out of the box on the default setup for several major
distros.

And as Stephen suggests, I would prefer not to make the test scripts
bash specific.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

Re: [PATCH] fdtget-runtest.sh: Fix failures when /bin/sh isn't bash

[David Gibson]

On Wed, Mar 21, 2012 at 02:26:53PM +1100, David Gibson wrote:
> On Tue, Mar 20, 2012 at 08:23:46PM -0600, Stephen Warren wrote:
> > On Ubuntu, /bin/sh is dash (at least by default), and dash's echo doesn't
> > accept the -e option. This means that fdtget-runtest.sh's EXPECT file will
> > contain "-e foo" rather than just "foo", which causes a test failure.
> > 
> > To work around this, run /bin/echo instead of (builtin) echo, which has
> > more chance of supporting the -e option.
> > 
> > Another possible fix is to change all the #! lines to /bin/bash rather
> > than /bin/sh, and change run_tests.sh to invoke sub-scripts using $SHELL
> > instead of just "sh". However, that would require bash specifically, which
> > may not be desirable.
> > 
> > Signed-off-by: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
> 
> Acked-by: David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org>
> 
> Jon, please apply.

Sorry Jon, you fell off the Cc list somehow.  Do you need me to resend
Stephen's patch to apply?

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

Re: [PATCH] fdtget-runtest.sh: Fix failures when /bin/sh isn't bash

[Jon Loeliger]

> On Wed, Mar 21, 2012 at 02:26:53PM +1100, David Gibson wrote:
> > On Tue, Mar 20, 2012 at 08:23:46PM -0600, Stephen Warren wrote:
> > > On Ubuntu, /bin/sh is dash (at least by default), and dash's echo doesn't
> > > accept the -e option. This means that fdtget-runtest.sh's EXPECT file will
> > > contain "-e foo" rather than just "foo", which causes a test failure.
> > > 
> > > To work around this, run /bin/echo instead of (builtin) echo, which has
> > > more chance of supporting the -e option.
> > > 
> > > Another possible fix is to change all the #! lines to /bin/bash rather
> > > than /bin/sh, and change run_tests.sh to invoke sub-scripts using $SHELL
> > > instead of just "sh". However, that would require bash specifically, which
> > > may not be desirable.
> > > 
> > > Signed-off-by: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
> > 
> > Acked-by: David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org>
> > 
> > Jon, please apply.
> 
> Sorry Jon, you fell off the Cc list somehow.  Do you need me to resend
> Stephen's patch to apply?

Please.  Last mail I saw on this issue was you saying "This patch isn't perfect." :-)

jdl

Re: [PATCH] fdtget-runtest.sh: Fix failures when /bin/sh isn't bash

[David Gibson]

On Mon, Mar 26, 2012 at 08:11:35AM -0500, Jon Loeliger wrote:
> > On Wed, Mar 21, 2012 at 02:26:53PM +1100, David Gibson wrote:
> > > On Tue, Mar 20, 2012 at 08:23:46PM -0600, Stephen Warren wrote:
> > > > On Ubuntu, /bin/sh is dash (at least by default), and dash's echo doesn't
> > > > accept the -e option. This means that fdtget-runtest.sh's EXPECT file will
> > > > contain "-e foo" rather than just "foo", which causes a test failure.
> > > > 
> > > > To work around this, run /bin/echo instead of (builtin) echo, which has
> > > > more chance of supporting the -e option.
> > > > 
> > > > Another possible fix is to change all the #! lines to /bin/bash rather
> > > > than /bin/sh, and change run_tests.sh to invoke sub-scripts using $SHELL
> > > > instead of just "sh". However, that would require bash specifically, which
> > > > may not be desirable.
> > > > 
> > > > Signed-off-by: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
> > > 
> > > Acked-by: David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org>
> > > 
> > > Jon, please apply.
> > 
> > Sorry Jon, you fell off the Cc list somehow.  Do you need me to resend
> > Stephen's patch to apply?
> 
> Please.  Last mail I saw on this issue was you saying "This patch
> isn't perfect." :-)

Uh, it was "this isn't perfect, but it's better than what we have,
please apply".

I've forwarded Stephen's patch to you again.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

Re: [PATCH] fdtget-runtest.sh: Fix failures when /bin/sh isn't bash

[Jon Loeliger]

> 
> Uh, it was "this isn't perfect, but it's better than what we have,
> please apply".

Sorry, I misunderstood.

> I've forwarded Stephen's patch to you again.

I've applied it.

jdl

Re: [PATCH] fdtget-runtest.sh: Fix failures when /bin/sh isn't bash

[Mike Frysinger]

[-- Attachment #1.1: Type: Text/Plain, Size: 888 bytes --]

On Tuesday 20 March 2012 22:23:46 Stephen Warren wrote:
> On Ubuntu, /bin/sh is dash (at least by default), and dash's echo doesn't
> accept the -e option. This means that fdtget-runtest.sh's EXPECT file will
> contain "-e foo" rather than just "foo", which causes a test failure.
> 
> To work around this, run /bin/echo instead of (builtin) echo, which has
> more chance of supporting the -e option.
> 
> Another possible fix is to change all the #! lines to /bin/bash rather
> than /bin/sh, and change run_tests.sh to invoke sub-scripts using $SHELL
> instead of just "sh". However, that would require bash specifically, which
> may not be desirable.
> 
> --- a/tests/fdtget-runtest.sh
> +++ b/tests/fdtget-runtest.sh
> 
> -echo -e $expect >$EXPECT
> +/bin/echo -e $expect >$EXPECT

the better fix is to use printf and %b:
	printf '%b\n' "$expect" > $EXPECT
-mike

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 192 bytes --]

_______________________________________________
devicetree-discuss mailing list
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH] fdtget-runtest.sh: Fix failures when /bin/sh isn't bash

[Stephen Warren]

On 11/02/2012 02:26 PM, Mike Frysinger wrote:
> On Tuesday 20 March 2012 22:23:46 Stephen Warren wrote:
>> On Ubuntu, /bin/sh is dash (at least by default), and dash's echo
>> doesn't accept the -e option. This means that fdtget-runtest.sh's
>> EXPECT file will contain "-e foo" rather than just "foo", which
>> causes a test failure.
>> 
>> To work around this, run /bin/echo instead of (builtin) echo,
>> which has more chance of supporting the -e option.
>> 
>> Another possible fix is to change all the #! lines to /bin/bash
>> rather than /bin/sh, and change run_tests.sh to invoke
>> sub-scripts using $SHELL instead of just "sh". However, that
>> would require bash specifically, which may not be desirable.
>> 
>> --- a/tests/fdtget-runtest.sh +++ b/tests/fdtget-runtest.sh
>> 
>> -echo -e $expect >$EXPECT +/bin/echo -e $expect >$EXPECT
> 
> the better fix is to use printf and %b: printf '%b\n' "$expect" >
> $EXPECT

What is the relative availability (e.g. on anything other than a
modern Linux distro) of a printf binary vs. a /bin/echo binary that
supports -e? I certainly heard about /bin/echo -e long before I knew
about /usr/bin/printf, although it's quite possible that has no
correlation with where /usr/bin/printf is actually installed.

Re: [PATCH] fdtget-runtest.sh: Fix failures when /bin/sh isn't bash

[David Gibson]

On Mon, Nov 05, 2012 at 10:39:30AM -0700, Stephen Warren wrote:
> On 11/02/2012 02:26 PM, Mike Frysinger wrote:
> > On Tuesday 20 March 2012 22:23:46 Stephen Warren wrote:
> >> On Ubuntu, /bin/sh is dash (at least by default), and dash's echo
> >> doesn't accept the -e option. This means that fdtget-runtest.sh's
> >> EXPECT file will contain "-e foo" rather than just "foo", which
> >> causes a test failure.
> >> 
> >> To work around this, run /bin/echo instead of (builtin) echo,
> >> which has more chance of supporting the -e option.
> >> 
> >> Another possible fix is to change all the #! lines to /bin/bash
> >> rather than /bin/sh, and change run_tests.sh to invoke
> >> sub-scripts using $SHELL instead of just "sh". However, that
> >> would require bash specifically, which may not be desirable.
> >> 
> >> --- a/tests/fdtget-runtest.sh +++ b/tests/fdtget-runtest.sh
> >> 
> >> -echo -e $expect >$EXPECT +/bin/echo -e $expect >$EXPECT
> > 
> > the better fix is to use printf and %b: printf '%b\n' "$expect" >
> > $EXPECT
> 
> What is the relative availability (e.g. on anything other than a
> modern Linux distro) of a printf binary vs. a /bin/echo binary that
> supports -e? I certainly heard about /bin/echo -e long before I knew
> about /usr/bin/printf, although it's quite possible that has no
> correlation with where /usr/bin/printf is actually installed.

That's the crux of the matter, really.  I just had a look on a FreeBSD
box I have access to and /bin/echo does *not* support -e, but there is
a printf(1).  So the /bin/echo -e approach is definitely no good,
printf might be but I don't know how widespread it is.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

Re: [PATCH] fdtget-runtest.sh: Fix failures when /bin/sh isn't bash

[Stephen Warren]

On 11/06/2012 12:26 AM, David Gibson wrote:
> On Mon, Nov 05, 2012 at 10:39:30AM -0700, Stephen Warren wrote:
>> On 11/02/2012 02:26 PM, Mike Frysinger wrote:
>>> On Tuesday 20 March 2012 22:23:46 Stephen Warren wrote:
>>>> On Ubuntu, /bin/sh is dash (at least by default), and dash's echo
>>>> doesn't accept the -e option. This means that fdtget-runtest.sh's
>>>> EXPECT file will contain "-e foo" rather than just "foo", which
>>>> causes a test failure.
>>>>
>>>> To work around this, run /bin/echo instead of (builtin) echo,
>>>> which has more chance of supporting the -e option.
>>>>
>>>> Another possible fix is to change all the #! lines to /bin/bash
>>>> rather than /bin/sh, and change run_tests.sh to invoke
>>>> sub-scripts using $SHELL instead of just "sh". However, that
>>>> would require bash specifically, which may not be desirable.
>>>>
>>>> --- a/tests/fdtget-runtest.sh +++ b/tests/fdtget-runtest.sh
>>>>
>>>> -echo -e $expect >$EXPECT +/bin/echo -e $expect >$EXPECT
>>>
>>> the better fix is to use printf and %b: printf '%b\n' "$expect" >
>>> $EXPECT
>>
>> What is the relative availability (e.g. on anything other than a
>> modern Linux distro) of a printf binary vs. a /bin/echo binary that
>> supports -e? I certainly heard about /bin/echo -e long before I knew
>> about /usr/bin/printf, although it's quite possible that has no
>> correlation with where /usr/bin/printf is actually installed.
> 
> That's the crux of the matter, really.  I just had a look on a FreeBSD
> box I have access to and /bin/echo does *not* support -e, but there is
> a printf(1).  So the /bin/echo -e approach is definitely no good,
> printf might be but I don't know how widespread it is.

Out of curiosity, does FreeBSD's sh's built-in echo accept the -e
option? In other words, did the switch to /bin/echo break anything there?

For reference, I just booted my ancient Red Hat 7.3 virtual machine, and
it has printf, so I guess it's fairly widely available.

A quick search yields the following:

http://old.nabble.com/Re%3A-portability-of-%27printf%27-command-td28144087.html

which comes to the conclusion that printf is widely available enough to
be OK.

Oh, and if you find "Portable Shell Scripting" by Peter Seebach on
Google Books or in print, page 18 discusses the portability of printf,
and concludes that it's almost pervasive.

Re: [PATCH] fdtget-runtest.sh: Fix failures when /bin/sh isn't bash

[David Gibson]

On Tue, Nov 06, 2012 at 10:27:46AM -0700, Stephen Warren wrote:
> On 11/06/2012 12:26 AM, David Gibson wrote:
> > On Mon, Nov 05, 2012 at 10:39:30AM -0700, Stephen Warren wrote:
> >> On 11/02/2012 02:26 PM, Mike Frysinger wrote:
> >>> On Tuesday 20 March 2012 22:23:46 Stephen Warren wrote:
> >>>> On Ubuntu, /bin/sh is dash (at least by default), and dash's echo
> >>>> doesn't accept the -e option. This means that fdtget-runtest.sh's
> >>>> EXPECT file will contain "-e foo" rather than just "foo", which
> >>>> causes a test failure.
> >>>>
> >>>> To work around this, run /bin/echo instead of (builtin) echo,
> >>>> which has more chance of supporting the -e option.
> >>>>
> >>>> Another possible fix is to change all the #! lines to /bin/bash
> >>>> rather than /bin/sh, and change run_tests.sh to invoke
> >>>> sub-scripts using $SHELL instead of just "sh". However, that
> >>>> would require bash specifically, which may not be desirable.
> >>>>
> >>>> --- a/tests/fdtget-runtest.sh +++ b/tests/fdtget-runtest.sh
> >>>>
> >>>> -echo -e $expect >$EXPECT +/bin/echo -e $expect >$EXPECT
> >>>
> >>> the better fix is to use printf and %b: printf '%b\n' "$expect" >
> >>> $EXPECT
> >>
> >> What is the relative availability (e.g. on anything other than a
> >> modern Linux distro) of a printf binary vs. a /bin/echo binary that
> >> supports -e? I certainly heard about /bin/echo -e long before I knew
> >> about /usr/bin/printf, although it's quite possible that has no
> >> correlation with where /usr/bin/printf is actually installed.
> > 
> > That's the crux of the matter, really.  I just had a look on a FreeBSD
> > box I have access to and /bin/echo does *not* support -e, but there is
> > a printf(1).  So the /bin/echo -e approach is definitely no good,
> > printf might be but I don't know how widespread it is.
> 
> Out of curiosity, does FreeBSD's sh's built-in echo accept the -e
> option? In other words, did the switch to /bin/echo break anything
> there?

Yes it does, so yes it does.

> For reference, I just booted my ancient Red Hat 7.3 virtual machine, and
> it has printf, so I guess it's fairly widely available.
> 
> A quick search yields the following:
> 
> http://old.nabble.com/Re%3A-portability-of-%27printf%27-command-td28144087.html
> 
> which comes to the conclusion that printf is widely available enough to
> be OK.
> 
> Oh, and if you find "Portable Shell Scripting" by Peter Seebach on
> Google Books or in print, page 18 discusses the portability of printf,
> and concludes that it's almost pervasive.

Ok, good to hear.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson