Hello, Responding to part of your message... On 2018-10-03, Sébastien Hinderer <Sebastien.Hinderer@xxxxxxxx> wrote: > In the same vein, I was wondering why the 'AC_SYS_INTERPRETER' macro > doesn't come in three variants, one for build, one for host and one for > target because I imagine that one may want to know whether #! is > supported on each of these platforms. Well perhaps not on the build > system, but, at least for us, that would matter for both host and > target. I would imagine that it's simply impossible for configure to determine whether #! scripts work on anything other the build system. So in the cross-compilation case, if your goal is to portably install scripts that run on the host or target system, you will presumably need to use a pessimistic default: that is, you must assume that #! scripts are not supported. You could add an option to override this behaviour (typically configure scripts implement these sorts of overrides via the cache variable mechanism). POSIX demands that when any command is executed (by the shell, anyway), if it does not start with #! and is not recognized as an executable binary file then it is executed as a shell script. So in the portable pessimistic default case the only kinds of scripts you can install are shell scripts that do not start with #!. The same behaviour is also mandated in recent editions for the execvp and execlp functions (I imagine this was standardizing widespread practice at the time). In practice I imagine (without proof) that something like #!/bin/sh is widely portable: that is implementations will either not support #! at all (and thus execute it as a shell script) or they will support it in the expected manner (also executing it as a shell script). Cheers, Nick _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
