Talk:Native shebang: Difference between revisions
→Problems
| (5 intermediate revisions by 2 users not shown) | |||
Line 4:
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. Following this, it
must print arguments on the command line, separated by spaces.
Background:
Line 37 ⟶ 38:
::Anyway, this is the best I can come up with for a task called "native shebang." --[[User:POP|POP]] ([[User talk:POP|talk]]) 05:59, 26 September 2014 (UTC)
::: It's not at all clear that a binary cannot begin with #! - if anything, that is an OS limitation (for example '#' corresponds to an 8086 AND opcode and the msdos COM file format is just executable code on the 8086 architecture with conventions added in an ad-hoc fashion). It's also not clear that this "self compiling application" does anything - actually, this is sounding more like a viral infection than a useful application. So let's say that the application does nothing - in that case, compiling can be a no-op. Do you see where I am going with this? --[[User:Rdm|Rdm]] ([[User talk:Rdm|talk]]) 07:38, 26 September 2014 (UTC)
::Since shebangs are a UNIX convention, I am thinking in terms of UNIX only. I forgot to add the default behavior which was part of the original proposal, which is to print arguments on the command line. I added it to the new wording. Most interestingly I see this as a way to demonstrate ways languages can compile code from within the language itself. The C example is not ideal, since it doesn't use internal facilities, but since not all languages have a built in compiler, this should be allowed. --[[User:POP|POP]] ([[User talk:POP|talk]]) 09:02, 26 September 2014 (UTC)
::After some thinking, I must say this task doesn't seem to make sense in terms of demonstrating programming techniques or language features. Any implementation in any language would just read the "script" file past the first line and then compile the remaining file into an executable. Most of the code is mundane and wouldn't demonstrate much anything unique to the different languages.
::On the other hand, compiling a file from within an application is something which would be interesting. This would be a distinct task, but the idea would be something like "accept a file as argument and compile the file into a binary executable without calling external applications. Only applicable to languages with a built-in compiler." --[[User:POP|POP]] ([[User talk:POP|talk]]) 10:35, 26 September 2014 (UTC)
==What is this task asking for?==
Line 52 ⟶ 59:
== Problems ==
The intro paragraph talks of a "third language" without identifying a second language (presumably the first language is the unix shell). Why? Is the "third language" a reference to the idea that C binaries are typically being "interpreted" by <code>ld.so</code>?
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"). --[[User:Rdm|Rdm]] ([[User talk:Rdm|talk]]) 2014-03-24T01:45:49
:If you are sure it doesn't work then flag it as incorrect and put any extra info to help in recreating your problem here in the talk page. --[[User:Paddy3118|Paddy3118]] ([[User talk:Paddy3118|talk]]) 07:04, 26 September 2014 (UTC)
Here is what I get on OpenBSD (and OSX). Note that I obtained script_gcc.sh from the unix shell implementation as there was no such file defined in the C implementation.
<pre>$ chmod +x /usr/local/bin/script_gcc.c /usr/local/bin/script_gcc.sh echo.c; ./echo.c Hello, world
./echo.c: line 6: syntax error near unexpected token `('
./echo.c: line 6: `int main(int argc, char **argv, char **envp){'</pre>
I was able to get it to work on Linux.
So I think (a) the C implementation should include the script_gcc.sh file, since that is a part of what it needs to run at all, and (b) the implementation should be documented as being non-portable, and only working on Linux. The task description should probably also be changed to more thoroughly document this volume of code that an implementation might need. Depending on how that task description issue handled, it may actually be that this task can only be solved on linux. --[[User:Rdm|Rdm]] ([[User talk:Rdm|talk]]) 23:21, 13 July 2015 (UTC)
| |||