FTBFS on systems without getconf

[ismaell]

Some systems don't provide getconf. The CHECK_POSIX_SH macro fails on those systems:

scrypt/m4/check_posix_sh.m4

Line 6 in c83b315

POSIX_PATH=`command -p getconf PATH`

It should, at least, behave like a standard macro and allow overriding the vaule from the command line.

[gperciva]

I believe that getconf is part of POSIX:
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/getconf.html

I can look into allowing people to override it, as a workaround for systems which are not POSIX-compliant.

[gperciva]

@Ismael: also, which system(s) don't have getconf? I should add a note in the BUILDING file about this.

I thought that the FTBFS acronym came from debian & ubuntu, but I can't see any open bug reports in their package trackers.

[ismaell]

The systems I'm dealing with right now are:

• Source Mage GNU/Linux, musl-libc variant (also, our default sh may vary)
• NuttX

On most systems the test doesn't make much sense because there should be only one sh in PATH, but on systems that matters, depending on the current PATH you may get different versions of getconf returning different answers, e.g. in Solaris:

• /usr/xpg4/bin/getconf
• /usr/xpg6/bin/getconf
• /usr/bin/getconf

I think the one in /usr/bin/ returns the same values as the one in /usr/xpg4/bin/...

In any case, should't the compliance be somehow tested? otherwise it's blind faith, and the system could be making bogus promises...

(yes, FTBFS came from Debian, but everyone understands it now and it's short 😃)

[gperciva]

Huh, NuttX looks cool!

Ok, this is a tricky thing that tests the bounds of POSIX compatibility, and I'm quite willing to believe that I got it wrong! This whole thing arose because of Solaris, namely #241 (fixed in #239 and #242).

My current understanding is that a POSIX-compliant system:

• command -p:

  Perform the command search using a default value for PATH that is guaranteed to find all of the standard utilities.
  https://pubs.opengroup.org/onlinepubs/9699919799/utilities/command.html

  So it shouldn't matter what PATH the user sets.

• command -p getconf PATH: retrieves that default PATH.

  In fact, the RATIONALE for getconf specifically notes:

  The original need for this utility, and for the confstr() function, was to provide a way of finding the configuration-defined default value for the PATH environment variable. Since PATH can be modified by the user to include directories that could contain utilities replacing the standard utilities, shell scripts need a way to determine the system-supplied PATH environment variable value that contains the correct search path for the standard utilities.
  https://pubs.opengroup.org/onlinepubs/9699919799/utilities/getconf.html

  ... come to think of it, the APPLICATION USAGE for command also gives that example:

  The order for command search allows functions to override regular built-ins and path searches. This utility is necessary to allow functions that have the same name as a utility to call the utility (instead of a recursive call to the function).

  The system default path is available using getconf; however, since getconf may need to have the PATH set up before it can be called itself, the following can be used:

  command -p getconf PATH
  https://pubs.opengroup.org/onlinepubs/9699919799/utilities/command.html

For more discussion,
https://unix.stackexchange.com/a/539014
https://unix.stackexchange.com/a/39245

Both command and getconf are part of the "standard utilities", so any POSIX-compliant system must supply them.

As for "blind faith"... well, we do test whether POSIX_PATH is non-zero; if it is, it gives an error. So we're not relying on bogus promises. :)

Anyway, I'm not opposed to allowing users to manually specify the path to a posix-compliant shell, but I still believe that this falls into the category of "workaround for a buggy OS".

[ismaell]

It's even more complicated than that:

• command might be built-in in the shell
• different versions of command might have different default paths (for their environment)
• which means different versions of getconf get run
• each version of getconf outputs potentially different and incompatible values

So, this approach is ok to get the default PATH for the environment that launched the configure script, but not necessarily gives you the most compliant posix shell available or any guarantees.

Unless you test the shell you don't know if it's OK. That's the whole point of a configure script.

[ismaell]

In any case, I thought autoconf scripts would run on pre-posix shells... don't they? or did autoconf 2.7x break that promise?

[gperciva]

In response to:

So, this approach is ok to get the default PATH for the environment that launched the configure script, but not necessarily gives you the most compliant posix shell available or any guarantees.

I'm sorry to repeat myself, but my understanding is that command -p getconf PATH is guaranteed to give us a PATH that contains a POSIX-compatible sh. I provided a few quotes of the POSIX specs which I believe demonstrates that. Did I read the POSIX spec incorrectly?

It doesn't matter if command is a shell built-in, or if there's multiple different POSIX-compatible sh binaries on the system. All we want is one of them [1]. We only use this to run our own set of POSIX compatibility checks in m4/check_libcperciva_posix.m4.

[1] for example, on Solaris we have:

td@solaris:~$ echo $PATH
/usr/bin:/usr/sbin
td@solaris:~$ which sh
/usr/bin/sh
td@solaris:~$ command -p getconf PATH
/usr/xpg6/bin:/usr/xpg4/bin:/usr/bin:/opt/developerstudio12.5/bin:/opt/solarisstudio12.4/bin
td@solaris:~$ PATH=$(command -p getconf PATH) which sh
/usr/xpg4/bin/sh

The last line is what we want.

[ismaell]

This is very system-dependent, and even environment-dependent, and there's no way to tell you're getting the correct one.

On Solaris, you can reasonably rely on it, but it truly depends on the first getconf you get being the correct one, and that will depend on the shell/environment.

The generalization, however, isn't reliable.

[gperciva]

You can now manually specify a path to sh with:

./configure POSIX_SH=/my/weird/path/sh