> The example file could as well have a shebang with a binary starting at line 2
> (think of some byte-code level interpreter, or some weird self-extracting
> archive) and it would still be classified as "text file" and interpreted by
> Bash.

This suggestion has merit. A file that starts with #! and the name of an invalid interpreter binary that contains binary data on the second and subsequent lines will be treated as a script. I think the best solution for this case is to check the first 128 bytes of the file if it starts with #!, rather than just the first line (where 128 is the maximum number of bytes bash reads from the file when checking).

>
> Anyways.
>
> Let's discuss possible workarounds for this issue instead. My off-the-hat
> ideas are:

You presume that your desired behavior is "correct" and "proper". We don't agree there. POSIX specifies the bash behavior, and nearly all shells behave the same way (see below).

>
> - Would a `set` option or some equivalent that enables the correct behavior
> from within a script be a viable option? It's less discoverable but we already
> teach developers to always use `set -e -o pipefail` and one item more in that
> list wouldn't hurt.

This is a minor issue that occurs extremely rarely. It's not worth a new shell option to do something oddball here.

> - Force-enabling the `HAVE_HASH_BANG_EXEC` compile option is an easy fix,
> although I'd consider it as a "distribution level" solution, which I'd like to
> avoid.

You are certainly welcome to do that.

> - Have a dedicated program to run a script that catches the ENOEXEC and
> handles it properly. Maybe we could integrate it into /usr/bin/env? Either
> way, it would require wrapping all calls with that program so it is not really
> practicable.

This is not appropriate for the shell. If the system is going to have a mechanism that handles ENOEXEC in this fashion, it should be generally available.

> - Switch away from Bash. I still have to check the behavior of more different
> shells, and check if one of them is syntactically sufficiently close to Bash.

Your choices are limited. Given a file with this content on my macOS system:

#! ./linux-binary
echo data 1
echo data 2

Bash, dash, ksh93, yash, gwsh, FreeBSD sh, and NetBSD sh all output

data 1
data 2

The only shells that catch ENOEXEC and print an error message are mksh (though it claims POSIX conformance) and zsh. Even the System V sh behaves like bash.

The example file you gave, which is something like

#! /path/to/binary
echo hello

is a text file.

Bash doesn't interpret #!: that's the kernel/dynamic linker's job. It only pays attention to #! on systems that don't handle it in the kernel, and those are rare these days.

If the execve system call returns ENOEXEC, bash behaves as specified in

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_01_01

and the bash documentation. After checking that the file doesn't appear to be binary, it executes the content as a shell script.

So, in your example, `bash -c ./test' turns into something effectively like `bash ./test'. This all happens in execute_cmd.c:shell_execve().

Steps to reproduce:

1. Cross-compile yourself an application for a different target. The target doesn't matter, it can even be for embedded/bare metal. (Actually, probably any ELF file that doesn't run on the host system in some way will do fine, but I haven't tested all possibilities yet).
2. Create a script file with that application as shebang and as content `echo hello world`, make it executable.
3. Execute it: `bash -c './test'`. For reference, also execute it with `sh` and `zsh` (sh has the same bug, zsh works fine).

Expected behavior:

An error like `bash: exec format error: /path/to/shebang` is printed and the command has a distinct (non-zero) exit code.

Actual behavior:

Bash ignores the shebang and interprets the script as usual. In this case, it will thus print "hello world". This gets especially funny when the script is for some other programming language.

-----

"Silently failing" is usually a pretty bad thing, but "silently deciding to just make stuff up if things failed" is an order of magnitude worse, thus I've marked this with a higher than normal severity.