Talk:Native shebang

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‎