Re: ./init.sh: line 139: `test-acos': not a valid identifier

[Ralf Wildenhues]

* Jim Meyering wrote on Thu, Feb 18, 2010 at 09:44:59PM CET:
> Ralf Wildenhues wrote:
> > 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.

> That sounds like a good idea, but does it work?
> 
>     $ bash -c 'alias a-b=echo; a-b'
>     bash: a-b: command not found

You need to enable alias expansion, gnulib-tool uses it, as example.

> > 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.

IIUC then it's not for MinGW.  It's only for cross setups where you have
an emulator but the host system doesn't emulate $EXEEXT-interpolation
for you.  Right?  (On MinGW, .exe is appended implicitly in all
interesting situations.)

> 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.

That's of course completely fine with me, the above offer was intended
as little more than another way out.

Cheers,
Ralf