Ralf Wildenhues wrote:
> * Eric Blake wrote on Thu, Feb 18, 2010 at 03:48:15PM CET:
>> According to Eric Blake on 2/18/2010 6:39 AM:
>> > For that matter, we should also try 'set +o posix' prior to looking for a
>> > better shell; it is certainly faster, and works for bash:
>> >
>> > $ /bin/sh -c 'a-b() { echo hi; }; a-b'
>> > /bin/sh: `a-b': not a valid identifier
>> > $ /bin/sh -c 'set +o posix; a-b() { echo hi; }; a-b'
>> > hi
>>
>> For that matter, with bash, we should use:
>>
>> $ /bin/sh -c 'set +o posix; a-b() { echo hi; }; set -o posix; a-b'
>> hi
>>
>> so that the rest of the script avoids any other bash extensions
>> incompatible with POSIX (does it strike you odd that bash lets you invoke
>> a function with an incompatible name, even though it won't let you define
>> it?).
>
> Given that bash may change this particular "feature" at any time without
> prior notice, this doesn't seem too safe to rely on.
>
> alias names are typically more relaxed, POSIX does not guarantee hyphens
> but dash, /bin/sh -> bash support them, Solaris sh doesn't but its ksh
> does.
Hi Ralf,
That sounds like a good idea, but does it work?
$ bash -c 'alias a-b=echo; a-b'
bash: a-b: command not found
FWIW, I have nearly-working code, using functions as
we (mostly Eric) have been outlining.
> Since I'd prefer standards-conforming code (FWIW): I volunteer to write
> a patch to add $EXEEXT to all test invocations in gnulib testsuite
> scripts and makefile sniplets now, and to try to revisit once every 6
> months, to please wine setups. If the gnulib authors can agree to that
> strategy, that is, of course.
Thanks for the offer, Ralf, but I feel pretty strongly
that adding $EXEEXT as a suffix to every invocation would
constitute "too much" pollution, and for what? To enable
mingw-like systems to run tests using a portable shell.
Gnulib itself is about enabling applications to code the right way,
targeting the best, most up-to-date interfaces. It would feel wrong
to compromise the aesthetics of a big chunk of the test suite in order
to accommodate less functional systems.
I'd much prefer to do a little more work to keep the tests readable,
while still enabling init.sh-using tests in most of those (fringe, IMHO)
environments, as long as they have a suitably modern shell.
Sticking to POSIX is fine as long as it doesn't impact code
quality (mostly readability and maintainability). However,
I've found that POSIX sh is too limiting in several respects
(lack of "local" support is a big one), so have decided to
require more, whenever feasible.
