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

[TomK]

Thanks very much Karl.  Appreciate this feedback. You've answered alot 
of the lingering questions I had around this topic.  Much appreciated!

Just for some continued open discussion, included some basic answers. 
Not meant to sway to one side or the other, just to understand reasoning 
behind what I see used.

On 7/30/2020 5:05 PM, Karl Berry wrote:
> 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.

access.redhat.com/solutions/715363

for i in `find /usr/include -type f `

fails on very large results.  $() has a higher results limit.  From an 
RH contact I used to work with several years back.  Nesting is possible 
as well $($(..)).

>      [] 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

A colleague used [] in a ksh script (Think it was ksh88) on a SLES 
system around 2009-2010.  Code was similar to this but not exactly.



if [ "`ps aux | grep ssh-[a]gent`" = 1 ]; then
    echo "Starting instance..."
    ssh-agent &
else
    echo "Running.  No action."
fi



After a couple of days, two instances existed in the process table.  The 
ps was correct, but the if statement still allowed the process to start 
from time to time.    Ran that through a few hundred tests and managed 
to replicate.  Occasionally, while ssh-agent was indeed running, another 
instance spawned. Adding that in [[]] prevented that issue. Once I try 
to dig up the specific notes from that time, I'll share.  ( Sorry for 
being a bit vague. Memory grows old.  )


>      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


--
Thx,
TK.