Re: configure: error: cannot find install-sh, install.sh, or shtool in "." "./.." "./../.."

[Nick Bowler]

On 25/07/2020, TomK  wrote:
> Out of curiosity and a bit on another topic.  Is the syntax written
> like this for compatibility reasons with other shells?  Or because it
> could get in the way of the parsers Automake uses?

Autoconf is primarily a portability tool and thus a key goal is for
generated configure scripts to run in pretty much any unix-like
environment that anyone could possibly want to run them on.

Although these days configure expects support for things like shell
functions and comments so you probably won't have much luck on the
original 1979 Bourne shell, but there are a lot of different ksh88
derivatives/workalikes still floating around which were the basis
for POSIX standardization and the default shell on basically every
unix-like environment you're likely to encounter outside of museums.

> Code snippet:
[...]
> In particular:
>
>
> "x$host_alias" != x;
>
>
> I know adding 'x' or another character prevents failures when a variable
> is empty but that's been deprecated for sometime.

I don't know of any shell that gets this wrong with empty variables.
But metacharacters are a problem.  For example, if we write:

  test "$a" != "hello"

then at least some shells, (e.g., heirloom-sh), fail if a="!" or
a="(", etc, even though it is valid according to POSIX:

  $ a='('
  $ test "$a" != "hello"
  test: argument expected
  $ echo $?
  1

Prefixing with a benign (usually "x") string neatly avoids this problem:

  $ test x"$a" != x"hello"
  $ echo $?
  0

It's simple enough to do that usually this pattern is applied everywhere
even in cases where it is not strictly necessary -- I don't need to know
whether or not host_alias can legitimately be set to '!'.

> [] is deprecated in favor of [[]]
> `` is deprecated in favor of $()

[[ ]] is not POSIX compliant, and won't work at all in many modern
shells including dash.

$() is POSIX but unfortunately not widely portable in practice, e.g.,
again in heirloom-sh:

  $ a=$(echo hello)
  syntax error: `a=$' unexpected

Cheers,
  Nick

Re: configure: error: cannot find install-sh, install.sh, or shtool in "." "./.." "./../.."

[Karl Berry]

Hi Tom,

Using this:

As shown in the Texinfo example, I think the order of the init and
config macros is important. Admittedly this is not clearly documented.

AC_INIT([...
AC_CONFIG_AUX_DIR([...
AM_INIT_AUTOMAKE([...
AC_CONFIG_HEADERS([...
AC_CONFIG_SRCDIR([...

Some variations are possible, but not arbitrary rearrangements. The
above order should work.  I did not see a case where you were trying
that.

Is the syntax written like this for compatibility reasons with other
shells?  

Yes. Automake (Autoconf too, and plenty more) has to work with any
/bin/sh. It long predates POSIX shells and cannot assume POSIX, let
alone bash. (For one thing, Solaris /bin/sh is still non-POSIX, as far
as I know.) Almost all shell code in other GNU packages tries to be
maximally portable, too.

Code snippet:
# FIXME: To remove some day.

Well, I didn't write that comment and don't agree with it :).

"x$host_alias" != x;
I know adding 'x' or another character prevents failures when a variable 
is empty but that's been deprecated for sometime.

I don't agree with "deprecated".

[] is deprecated in favor of [[]]

I don't agree with "deprecated". Also, single and double brackets are
two quite different things. Double brackets must not be used by
shell code that needs to be portable; they're a bash/etc. extension.

`` is deprecated in favor of $()

I don't agree with "deprecated". Left quotes must continue to work
forever and there is every reason to use them, in shell code that must
be maximally portable.

[] also return false positives allowing conditions to execute in cases 
where they shouldn't.  

Have to see an example. I am fairly certain that [...] does not have
actual bugs in this regard, barring some truly obscure systems. It is
certainly possible to get unexpected results when not used properly.
See "test" in the node
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Limitations-of-Builtins.html#Limitations-of-Builtins

Not sure about test though.

test and [ are synonyms. Maximally portable code should use test,
however, because of old os's which could misparse [ ... ] when the ...
contained another ].

See the (long) chapter in the Autoconf manual about shell portability
for the basis of most of the shell usage in autotools. (The previous url
is one )
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Portable-Shell.html#Portable-Shell

Best,
Karl