On 31/10/2025 09:25, Bruno Haible wrote:
Collin Funk wrote:
Note the above ENOEXEC fallback issue also impacts sort --compress,
but that's a less general use case so I don't think it's worth
worrying about or changing anything for. We could document that
change in behavior though in NEWS.
I've just pushed a "Change in behavior" note to NEWS
mentioning sort --compress-program will not use the /bin/sh fallback.
Good point. I didn't notice. The GNU Make example that Bruno linked has
two posix_spawn invocations to handle this [1].
[1] https://sources.debian.org/src/make-dfsg/4.4.1-2/src/job.c?hl=2450#L2450
Refusing to execute a text file without shebang (or even an unknown binary type)
like it were a /bin/sh script is seen as a feature (for security) nowadays. See
https://www.austingroupbugs.net/view.php?id=1674
https://sourceware.org/bugzilla/show_bug.cgi?id=13134
https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=d96de9634a334af16c0ac711074c15ac1762b23c
https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=13adfa34aff03fd9f1c1612b537a0d736ddb6c2b
It is understandable that GNU make has special provisions, for backward
compatibility. The same argument need not necessarily apply to
'sort --compress' and 'timeout'.
I see timeout(1) as having similar portability concerns as make(1),
so I think it's ok/best for now to leave the sh fallback in timeout.
In general if one was to address that issue it would be best to
do at the libc level rather than every app that might invoke exec..()
Thanks for the info.
Padraig