Hi Jim, Stefano, Thanks for your comments.
On 28 Jan 2013, at 03:07, Jim Meyering <j...@meyering.net> 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)
