That's bugs in those shells for POSIX mode then, that I see. The conforming behavior is /usr/gcc is found and succeeds at doing nothing, since it contains just a comment line. Other elements of path never get checked. Even in non-POSIX mode, trying to process it as a shebang with "/bad" as a ENOEXEC because not present, or other reason, does not imply the rest of the path should be searched, it should simply return a failure code. On Sun, Apr 11, 2021 at 6:07 AM, Harald van Dijk via austin-group-l at The Open Group<austin-group-l@opengroup.org> wrote: On 10/04/2021 17:08, Robert Elz via austin-group-l at The Open Group wrote: > Date: Sat, 10 Apr 2021 11:54:34 +0200 > From: "Jan Hafer via austin-group-l at The Open Group" ><austin-group-l@opengroup.org> > Message-ID: <15c15a5b-2808-3c14-7218-885e704cc...@rwth-aachen.de> > > | my inquiry is a question about the potential unexpected behavior of the > | shell execution environment on names. It is related to shortcomings of > | the command utility. > > I'm not sure I understand. I read the rest of the message, and I > couldn't find anything really about any shortcomings, other than perhaps > some mistakes in interpretation, and usage.
If they are mistakes, they are widespread mistakes. As hinted in the links, with PATH=/bin:/usr/bin, /bin/gcc and /usr/bin/gcc both existing as files with execute permission, but /bin/gcc as a text file containing #!/bad so that any attempt to execute it will fail, there are a lot of shells where command -v gcc returns /bin/gcc, but running gcc actually executes /usr/bin/gcc instead without reporting any error: this behaviour is common to bosh, dash and variants (including mine), ksh, and zsh. Cheers, Harald van Dijk
