Re: [PATCH] bootstrap: remove the need for a sorted .gitignore

[Gary V. Vaughan]

Hi Jim, Stefano,

Thanks for your comments.

On 28 Jan 2013, at 03:07, Jim Meyering <address@hidden> wrote:
> Stefano Lattarini wrote:
>> Throwing in my two cents here ...
> ...

Stefano, I didn't get a copy of your message for some reason, only Jim's
reply :-o

>>> $(...) is not supported by even some modern systems, including solaris 10.
>>> 
>> Actually, only by /bin/sh.  Solaris 10 has a working Korn shell in
>> /bin/ksh and a working POSIX shell in /usr/xpg4/bin/sh.  Requiring
>> a developer to use them to run the bootstrap doesn't seem a harsh
>> requirement to me.

That's true to some extent.  However, I don't have the capacity to do a good
job of writing code to two different standards depending on whether it shows
up in a maintainer script or an end-user script... and in some cases the line
is blurred, such as my funclib.sh/extract-trace libraries that are used in both
bootstrap rewrite, and in ltmain.sh (and therefor eventually inside the user's
libtool script).

I also occasionally cross-pollinate shell functions between programs, and
will likely forget to rewrite the syntax back and forth when I do that.  It's 
bad
enough trying to remember to quote [] in regexps when moving a raw shell
function into an Autoconf library, and vice versa.

>>> Better to use `...`, although this problem is rampant in bootstrap too, so
>>> not the fault of this patch... even so, that's no reason to compound the
>>> error.
>>> 
>> I think that, at least in maintainer-specific scripts, we should move
>> away from old Bourne shell idioms and just require a POSIX shell, as
>> of *now*.
> 
> I agree, wholeheartedly.
> That is precisely why I've insisted on using $(...)
> and not `...` in bootstrap.

While $(...) is most definitely a nicer syntax, it is certainly not as portable
as `...`.

But, I'll look into generalizing autoconf's shell rexec machinery for some
additional boiler-plate to paste into the start of all my scripts in the hope
I can stop having to worry about such things.

>> Autoconf-generated configure scripts should follow suite (but
>> changing Autoconf internals in that direction won't be trivial, so that
>> will likely take more time).
> 
> I'm looking forward to that, and the resulting
> cleaner/smaller configure scripts.

Autoconf internals would benefit far more from greater use of functions than
fussing over backticks IMHO.

Even so, I'd like to see somewhere (I guess in the Shellology section of the
Autoconf manual?) that definitively lays out what the *current* best practice
for portable shell syntax choices consensus is - for example: "$(...) is 
generally
preferred in maintainer-only scripts, but if you need to share a function using
that syntax with a portable end-user script, be prepared to run a shell search
and re-exec at the start of that script to be sure of $(...) support, or else
remind your Solaris users that they will need to ensure the script is never
seen by /bin/sh, which does not accept this newer POSIX syntax."

Similarly, I can never remember whether use of return in shell functions is
portable, or whether I can actually return a value or merely use it to leave a
function before reaching the end.

>>> so it would be safer to probe for
>>> and use a backslash safe echo here
>>> 
>> Much better would be to just use printf.  Safer, simpler and more portable!
> 
> Yes.  For uses like this, echo has been deprecated
> for well over a decade.

And here's another one :)  What users (if any) will I be leaving behind if
the next libtool release ejects all the echo probing gunk in favour of uniform
use of printf throughout?

There are certainly other areas where I default to old-school portability, and
might be obfuscating my scripts unnecessarily if I'm inadvertently pandering
to museum pieces, and until someone kindly points me to the evidence of
my errors I'm not even aware of where all those opportunities to improve and
modernize will lie.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)