Wrong interpreter

Posted Feb 18, 2019 22:20 UTC (Mon) by rgmoore (✭ supporter ✭, #75)
In reply to: Wrong interpreter by rfunk
Parent article: The case of the supersized shebang

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.