Harald van Dijk <a...@gigawatt.nl> wrote:
> >> 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.
> >
> > My tests show that ksh, bash, yash, mksh do not find gcc in that case.
>
> Huh. My tests with ksh were with 93v, it's possible different versions
> behave differently.
Do you have a private variant og ksh93v?
I get the same behavior from ksh88, the ksh93 from OpenSolaris and ksh93v.
> I am assuming that by "do not find gcc" you mean "do not find
> /usr/bin/gcc" here.
As mentioned in another post, the error is ENOENT, caused by execiting the
#!/bad script. So unlike the Bourne Shell, ksh does not use the hash as start
index for further searching but rather as a definite value.
> > I believe what bosh and dash do is the best behavior. None of the known
> > shells
> > opens the file with "command -v something" and thus cannot know whether the
> > content is a script, a useless #! script or even a binary for the wrong
> > architecture.
>
> Earlier, you did not see the problem that prompted this thread, and now
Well, with 40 years of UNIX history experience, you have so many exceptions to
remember that you do not always remember every detail and the OP could at least
give a hint.
> you say that the behaviour where command -v lookup does not match
> execution lookup is the best behaviour. I trust that you do see now the
> problem that prompted this thread: there is, in these shells at least,
> no reliable way to perform command lookup separate from execution.
This is indeed a problem that that would need a coordinated change in all
shells.
Fortunately, the problem is only present on missconfigured environments. It can
be avoided by admins...
> I don't think command -v should do more, I think ordinary command lookup
> should do less. The behaviour of shells of continuing command lookup
> after a failed execve() is not supported by what POSIX says in "Command
> Search and Execution". Command lookup is supposed to stop as soon as "an
> executable file with the specified name and appropriate execution
> permissions is found" (per the referenced "Other Environment Variables",
> "PATH"). In my example that results in /bin/gcc. The shell should
> attempt to execute /bin/gcc, and once that fails, stop.
Given that #!/bad causes an ENOENT, this seems to be a missinterpreation from
you. The shell cannot distinct the missconfigured script from a missing file.
> > There is still a problem: only bosh and ksh could in therory add the right
> > entry into the hash, since they are using vfork() and could report back the
> > final result via shared memory. I have that probability in mind for bosh
> > since
> > I introduced vfork() support to bosh in 2014.
>
> That's an interesting thought. The approach taken by the other shells
> avoids the problem entirely and makes this unnecessary though.
Not by all shells, see e.g. dash.
The Bourne Shell and dash behavior seems to be the expected behavior since I
would not first look at how the hash entries are created in order to judge on
the real execute behavior.
Jörg
--
EMail:jo...@schily.net Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/
http://sourceforge.net/projects/schilytools/files/
