Wrong interpreter

Posted Feb 18, 2019 19:53 UTC (Mon) by rfunk (subscriber, #4054)
Parent article: The case of the supersized shebang

So if I understand the situation correctly, this patch was intended to avoid *maybe* getting the wrong interpreter (a situation that Unix users have known about for some 40 or 50 years) by falling back to the default shell -- which is almost certainly the wrong interpreter!

If someone wanted to fix this longstanding misbehavior, the sensible approach would be to expand the interpreter-string buffer (maybe dynamically), not make over-long interpreter strings cause a fallback to a completely different interpreter.

Wrong interpreter

Posted Feb 18, 2019 21:16 UTC (Mon) by jhoblitt (subscriber, #77733) [Link]

The 128 char limit sounds like a lot but it has caused by a fair amount of grief over the years with build/CI systems with deep directly structures that host a copy of an interpreter in the bottom most leaves. It would be fantastic if this could be increased, perhaps a sysctl default of the old 128 char limit.

Wrong interpreter

Posted Feb 18, 2019 22:20 UTC (Mon) by rgmoore (✭ supporter ✭, #75) [Link] (4 responses)

It's not just that they might get the wrong interpreter or (potentially more worrisome) get the right interpreter with a mangled set of parameters. It's that at least some of the interpreters are smart enough to re-read the first line just in case it was truncated. Honestly, re-reading the shebang line seems like the right thing for the interpreter to do. The line is right there in the script that the interpreter has to read anyway, and it's documented that at least one operating system will mangle the line if it's too long. Why wouldn't an interpreter reread it?

Wrong interpreter

Posted Feb 19, 2019 3:25 UTC (Tue) by gdt (subscriber, #6284) [Link]

From the interpreter author's point of view, they probably encountered this issue as non-program text appearing before the program text; their initial interest was unlikely to be around support of long argument lines but dealing with a compile bug.

The interpreter authors were doing the 'right' thing: using the system library as intended and documented in the manual. That's why it doesn't initially occur to interpreter authors to re-construct the command line from argv and from the program text and then use a non-system parser to re-parse the command line options.

Wrong interpreter

Posted Feb 19, 2019 14:01 UTC (Tue) by NAR (subscriber, #1313) [Link] (1 responses)

The example Erlang script (escript) starts like this:

#!/usr/bin/env escript
%% -*- erlang -*-
%%! -smp enable -sname factorial -mnesia debug verbose

The first line is the portable shebang. Second is simple comment (maybe interpreted by emacs?), the third line also looks like a comment, but parsed by the interpreter and contains arguments for the interpreter. I guess this is done this way due to the limitations of /usr/bin/env so it cannot pass arguments directly to the interpreter. This seems to be a sensible approach.

Wrong interpreter

Posted Feb 19, 2019 18:30 UTC (Tue) by rweikusat2 (subscriber, #117920) [Link]

-*- language -*- close to the start of some text file causes Emacs to switch to the major mode for language.

Wrong interpreter

Posted Feb 19, 2019 15:08 UTC (Tue) by anton (subscriber, #25547) [Link]

Gforth treats #! as starting a comment line.

Why not reread the #! line and interpret it? Because treating it as a comment is simpler, by quite a lot. Consider a gforth script script that is invoked with

./script scriptarg1 scriptarg2

and starts with

#! /usr/bin/gforth gfortharg

Then the kernel constructs the following command line:

/usr/bin/gforth gfortharg ./script scriptarg1 scriptarg2

Note that gforth processes gfortharg before the rest of the command line. Then, when it sees ./script, and the #! at its start, it might start doing something about this line. But why, given that the kernel already does it nicely (well, in most cases at least)?

One advantage of doing your own processing is that one could have more than one argument on the #! line, as demonstrated in the Perl case, but for now the pain has not been big enough to go to these lengths.

Wrong interpreter

Posted Feb 19, 2019 19:00 UTC (Tue) by dona73110 (guest, #113155) [Link] (2 responses)

> So if I understand the situation correctly, this patch was intended to avoid *maybe* getting the wrong interpreter (a situation that Unix users have known about for some 40 or 50 years) by falling back to the default shell -- which is almost certainly the wrong interpreter!

That's what corbet said but it's not exactly what's happening - if you look at the patch there's no default to a shell, it just returns an error that the file was not executable.

The shell is the one that takes this "can't execute" error as a cue to interpret the file shell instead :-x

Wrong interpreter

Posted Feb 19, 2019 19:11 UTC (Tue) by rfunk (subscriber, #4054) [Link] (1 responses)

Wherever the shell fallback is implemented, the result is the same, so that seems irrelevant unless you're also going to patch all the shells that implement that fallback.

Wrong interpreter

Posted Feb 20, 2019 6:49 UTC (Wed) by marcH (subscriber, #57642) [Link]

Falling back on the default shell is not the same than falling back on the current shell.