Suggestion for a new wording

Native interpeter for #! aka shebang

Write a "script" file in your programming language which starts with #! (aka shebang) and is followed by a path to a binary executable compiled from the same script file. The executable must then rebuild itself using the contents of the script file.

Background: A shebang line (first 2 bytes of the file are #!) is a message (magic word) on UNIX systems which indicates to the loader/exec function that the following line should be used as a path and arguments to a call to exec, with the argument 0 set to the executable after the shebang, and argument 1 set to the path of the file itself.

The effect is that by using a shebang line, we can have a file executed by the specified interpreter. The interpreter must be a binary file executable on the system.

Programming languages which cannot generate a binary executable should ignore this task. --POP (talk) 16:02, 25 September 2014 (UTC)

Where should the "binary executable" be written? --Rdm (talk) 18:35, 25 September 2014 (UTC)

What is this task asking for?

I don't quite understand what this task is asking for, as arguably what it asks for is how many language implementations already work under the covers. In what way would #!/usr/bin/python not be a reasonable way of achieving it with Python? (All /usr/bin/env really adds is convenient path searching.) –Donal Fellows (talk) 04:30, 3 September 2013 (UTC)

Near as I can tell (and judging by the examples), the task is asking for you to write a program in language Foo that can be run by a shebang in another Foo language file as a way of executing the second file. For example, a C++ solution would have you place #!/some/where/run_cpp_file at the top of a C++ file (call it myprgm.cpp), and then you would be able to do the following:

chmod u+x myprgm.cpp
./myprgm.cpp

At which point run_cpp_file (originally written in C++) is called to compile and run myprgm.cpp. I personally think this is abusing the purpose of a shebang; languages that aren't compiled to some binary form before being run, such as Ruby or Perl already have existing suitable shebang mechanisms (this is even mentioned as a "difficulty": "Naturally, some languages are not compiled. These languages are forced to use shebang executables from another language, eg "#!/usr/bin/env python""). Languages compiled to a binary form, on the other hand, would more naturally use Makefiles and similar to accomplish the same kind of thing, that is "run with one or two simple commands". Lue (talk) 02:49, 2 February 2014 (UTC)

That still doesn't answer my central point: In what way does a Python program that starts with:

<lang python>#!/usr/bin/python</lang>

not totally answer this task? The task description seems to imply that it doesn't, but I don't understand what it means. Do not answer by talking about languages that normally have a separate compilation step, as that doesn't help to clear up the confusion; state clearly with reference to Python or one of the large number of other languages for which this is possible. (My hunch is that this is all something that doesn't make sense outside the scope of maybe one or two languages. A program is a program! What's more, the line between interpreted and compiled is very blurry.) –Donal Fellows (talk) 17:25, 19 April 2014 (UTC)

Problems

The intro paragraph talks of a "third language" without identifying a second language (presumably the first language is the unix shell). Why?

The C example doesn't work for me (unless a segmentation fault from script_gcc.sh can be described as "working" or a bad interpreter error from echo.c can be described as "working"). --Rdm (talk) 2014-03-24T01:45:49‎