Re: misc/23729 (please add a FAQ on the 'Syntax error: "(" unexpected' ld.so issue)

[kre%NetBSD.org@localhost]

Synopsis: please add a FAQ on the 'Syntax error: "(" unexpected' ld.so issue

State-Changed-From-To: open->feedback
State-Changed-By: kre%NetBSD.org@localhost
State-Changed-When: Fri, 17 Jun 2022 05:32:43 +0000
State-Changed-Why:

Can we close this PR?

In the intervening time, the world has changed.  When the run time linker
is missing, systems (including ours) now seem to all report ENOENT
to the exec attempt - when that happens the shell assumes that the path
name it passed to the kernel doesn't exist (any more, in many cases it
just previously found it via a PATH search) and simply does nothing more.

Also, /bin/sh now does a check for exec'ing ELF format files, and no
longer tries to run them as scripts, when the simple exec fails (if you
ask to run it as a script "sh file" then it will attempt it of course).

Not sure about /bin/ksh - but as long as the kernel is returning ENOENT
in the case in question, it also doesn't have the problem reported.

In any case, I don't think we really need (any more) a FAQ about this
particular issue.

FWIW: I believe our (and almost everyone else's) kernel to be broken in
this area, once it has determined that the file passed to exec exists,
checked permissions, checked its format (and all the other stuff it
checked before deciding to allow an exec), it should stop reporting any
more specific errors, anything which fails after that point (which includes
the attempt to find /libexec/ld.elf_so, or the interpreter listed in a
#!, or where the user lacks permission to run that, or anything similar
(like a "ln -s /etc /etc" symlink ELOOP error) should be reported as
ENOEXEC, that is, there is something wrong with the file being exec'd
and we cannot do that.

That systems don't do this was reported as a bash bug just recently,
(wrt some linux version or other) with a request that bash look at
ENOENT errors returned, and work out what was not found, so the error
message doesn't appear to be saying that the command named doesn't exist
where the user can clearly see with "ls" that it does.   Having a shell
do the work for that would be absurd, even having it add weasel words
(which was a watered down request) so that ENOENT errors would be reported
as something like "file doesn't exist or some other file needed to run it
doesn't exist" is fairly dumb, when the obvious correct thing to do is to
fix the kernel to map all those late errors into ENOENT.

But none of that is an issue for this PR.  I just felt like a rant!