On Mar 20, 2018, at 4:07 AM, R. Diez <rdiezmail-temp2@xxxxxxxx> wrote: > > I know that Autoconf developers want to write extremely portable scripts. But that is a huge barrier for somebody like me. I am a user, not a shell expert. Your argument attempts to have it both ways: Bourne and POSIX shell is too old to still be used, you say, but learning old shells is too difficult. The thing is, these old shells were state of the art on systems so small by today’s standards that they barely even qualify as computers: - The acme of individually-accessible computing when the Bourne shell was high technology was the PDP-11, which couldn’t even achieve 1 MIPS on benchmarks so old now that we don’t even use them any more. (“1 MIPS” was defined in terms of the PDP-11’s successor, the VAX 11/780.) - The acme when POSIX was first ratified was the SPARCstation 1, which was outdone by Palm PDAs at their height of popularity. A smartwatch runs circles around the old PDAs now. So, could software meant for those machines really have been all that complex? > I have heard that the POSIX standard, or maybe its implementation, is not exactly the same across all shells. There are subtle differences. Doubtless one could find multiple odd corner cases still in existence, yet we find that shell scripts are broadly portable in practice. How do you square that with the FUD line? All of the shell incompatibilities I’ve come across have been in the other direction: someone raised on nothing but Bash-based systems writes some Bash-ism into a script, puts a #!/bin/sh at the top, then releases it to the world, where it breaks everywhere that /bin/sh is not Bash. > The generated 'configure' script changes shells on start-up. The logic is not documented. I looked inside, and it was not immediately obvious on what grounds some shells are preferred. Depending on what is installed, I seems possible that zsh is taken, for example. What’s wrong with that? It’s upgrading from worse shells to be better shells for you, where possible. Were you thinking that zsh is not compatible with the POSIX and Bourne shell languages, perhaps? > I am unwilling to test my configure.ac on several shells. Are you willing to accept bug reports from your software’s users, then, when it won’t configure on their non-Bash based OS? > Furthermore, the features in the POSIX standard are very limited. I remember when POSIX features were unattainable, being either difficult or effectively impossible to find everywhere I wanted my software to run. I could get behind your argument if you were fighting for a *good* language, but Bash? What weak sauce! Bash is wonderful for what it is, but it’s horribly hampered by compatibility and nailed-in-place standards. If we’re going to throw out the requirement for least-common-demoninator standards, our options open up to many far better scripting languages. Instead of fighting for Autoconf-with-Bash, consider Autosetup: https://msteveb.github.io/autosetup/ <https://msteveb.github.io/autosetup/> It ships with a minimal implementation of the Tcl programming language and enough smarts to bootstrap it on systems where a local Tcl doesn’t exist. Because it uses either a) your local Tcl, which is likely to be recent, or b) Jim Tcl <http://jim.tcl.tk/index.html/doc/www/www/index.html>, which understands a modern Tcl dialect, you aren’t tied to a decades-old version of the scripting language, as with Autoconf. Yet, the language is far cleaner than Bash 4, because it has a much simpler development history. Now you’ve got some real power, using a regular, improving syntax. Just to pick one example, modern Tcl has associative arrays, and has had them since 2003. Bash didn’t get them until 2009, but that’s not the salient point here. The important thing is that the POSIX shell doesn’t have them, so when it comes to portability, you can’t count on them. Autosetup sidesteps that problem by depending on a language that wasn’t nailed in place in 1989 in an effort to stop the Unix Wars, resulting in it not moving forward in a compatible way from that point. > I am using arrays and regular expressions, for example. An my scripts are not really that complex. Tcl has those, too. :) > I do not know of any shell linters like ShellCheck that accept configure.ac files. Analysis tools should accept configure scripts. I wouldn’t expect an Autoconf-produced configure script to pass any reasonably strong linter, though. It’s machine-generated code, so it’s probably “horrible” from a bondage-and-discipline standpoint. It’s meant to be understood by shells, not by other humans. > I would be very happy if my software ran on 10 % of the platforms where Bash is installed by default. There’s a wonderful idea in philosophy, which is that laws should be written as if legislators did not know their eventual place in society when they left the legislature. Think how different our laws would be if that were the case. I think you’re suffering from the same problem as our legislators here, where you believe you get to choose both the rules and your software’s place in the world governed by those rules. What if *I* get to choose the 10% of platforms your software will run on? I wave my Wand of Will, and tell you that your software will run only on Slackware Linux, WSL, and pre-macOS versions of OS X. If you are not using one of these today, you must either switch platforms if you want to run your software. Are you still happy with 10%? > In fact, it is the only sane solution. Either you just labeled all of us successful Autotools users insane, or your logic has a hole in it. > My guess is that Autoconf-generated 'configure' scripts usually work because they tend to switch to Bash on start-up. Your guess is uninformed, else no Autotools-based software would port to any system not based on Bash, yet this regularly does occur. In fact, that’s Autotools’ original purpose. > Even if you really wanted, there is no way to properly test your configure.ac scripts. Sure there is: try it everywhere. In today’s worlds of near-free VMs and OS images, you have less excuse than ever before not to do that. Before cheap VMs existed, we’d just put our software out on the Net and wait for the complaints to roll in, which we’d fix one by one, until our software was deemed “portable.” Portability is not a static state of being. > Autoconf requires a Bourne shell, but exactly what is required, is not documented. Sure it is. We have the source code to the 1979 Bourne shell. It’s right here: https://github.com/dspinellis/unix-history-repo/tree/Research-V7-Snapshot-Development/usr/src/cmd/sh <https://github.com/dspinellis/unix-history-repo/tree/Research-V7-Snapshot-Development/usr/src/cmd/sh> That software saw very wide distribution, so if you want “documents” instead of source code, I could bury you in documents, if I wanted to. If you want software that runs on a modern system, I’d recommend “osh” from the Schily Tools, or as a fallback, the Heirloom Bourne Shell: http://schilytools.sourceforge.net/bosh.html <http://schilytools.sourceforge.net/bosh.html> http://heirloom.sourceforge.net/sh.html <http://heirloom.sourceforge.net/sh.html> > There is no guide as to what shells and shell versions you should be testing against. I wrote an article that should get you oriented: https://unix.stackexchange.com/a/145524 > It is 2018. No wonder so many people want to ditch Autoconf! Name me an alternative, and I can give you a list of problems with it, too. As you can tell from my Autosetup advocacy above, I also have substantial interest in getting away from the Autotools, but even my latest fancy has its problems, the biggest being that it doesn’t work on Windows, short of being hosted in a Linux emulation environment like Cygwin or WSL. Nothing’s perfect. _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
