Re: How to change the shebang in 'configure' to require Bash

[Warren Young]

On Mar 20, 2018, at 4:07 AM, R. Diez <address@hidden> 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.