> On 2021/01/09 23:52, n952162 wrote: >> I consider it a bug that bash (and its hash functionality) includes >> non-executable files in its execution look-up
Of course, as described in the manual page, Bash first searches for an executable with the right name in the PATH, and then if that fails, it searches for a non-executable file in the PATH. The first part resembles one of the exec() functions and seems reasonable, but the second is weird. My belief is that the reason is compatibility with historical usage. I have dim memories that there were days before shell scripts had the executable bit set and the first line started with "#!". Instead, they weren't marked as executable but the first line started with ": " (either mandatory or by convention). And the scripting facility was implemented entirely in the shell -- if the shell's call to the kernel to execute the script failed, it would decide that the file was a script, then spawn and initialize a subshell to execute it. Of course, there was no check that your file actually was a script, so if you had named a data file, the subshell would spew a stream of errors. But the consequence to this day is that scripts without the executable bit can be executed if they are given as command names to bash, and that executable scripts take precedence over similarly-named non-executable scripts earlier in PATH. Dale
