chris on Nostr: TIL that on FreeBSD, the interpreter in the shebang line of a script must be a binary ...
TIL that on FreeBSD, the interpreter in the shebang line of a script must be a binary executable (presumably ELF), not a script or similar. On Linux, using a script as an interpreter is totally cool. The fix is easy: just use #!/usr/bin/env in the shebang line, which is probably a good idea anyway. If your shebang line does happen to point to a script, execution doesn’t fail. Oh no. Instead, the system shell is invoked with whatever you were trying to pass to some other interpreter. This is absolutely terrible. Instead of getting a sane error message like “Sorry Dave, I can’t do that, and here’s why”, you’ll get some bizarre syntax error from the shell … if you’re lucky! If you are particularly unlucky, then who the fuck knows what will happen. Your guess is as good as mine.
Somewhat relatedly, the following has made its rounds on HN and Lobsters more than once: Actually Portable Executables. For people who haven’t seen it, this is basically a technique to create a “polyglot” x86 binary that runs on Unix, DOS/Windows, Mac, bare metal, and so forth. On Unix, this works by exploiting an ancient misfeature that has evidently been codified in bloody POSIX. Here’s a longish quote from the post:
One day, while studying old code, I found out that it’s possible to encode Windows Portable Executable files as a UNIX Sixth Edition shell script, due to the fact that the Thompson Shell didn’t use a shebang line. Once I realized it’s possible to create a synthesis of the binary formats being used by Unix, Windows, and MacOS, I couldn’t resist the temptation of making it a reality, since it means that high-performance native code can be almost as pain-free as web apps. Here’s how it works:
There are already plenty of ways to use the wrong interpreter on the wrong code. This one would be easy to prevent. But nope, likely not gonna happen, at least on POSIX systems.
Published at
2023-06-27 06:33:39Event JSON
{
"id": "6ef11d7e76bf449c422c93e3e67a4c7ba278d3f8b24508e573657d3d3415361f",
"pubkey": "c277828b6467d7ffc6a6d444d1bdaa11b3d8445db404f0b4c96326e46d942d93",
"created_at": 1687847619,
"kind": 1,
"tags": [
[
"mostr",
"https://s.the-brannons.com/objects/e7b8e813-298f-4693-a383-7e8432840b8e"
]
],
"content": "TIL that on FreeBSD, the interpreter in the shebang line of a script must be a binary executable (presumably ELF), not a script or similar. On Linux, using a script as an interpreter is totally cool. The fix is easy: just use #!/usr/bin/env in the shebang line, which is probably a good idea anyway. If your shebang line does happen to point to a script, execution doesn’t fail. Oh no. Instead, the system shell is invoked with whatever you were trying to pass to some other interpreter. This is absolutely terrible. Instead of getting a sane error message like “Sorry Dave, I can’t do that, and here’s why”, you’ll get some bizarre syntax error from the shell … if you’re lucky! If you are particularly unlucky, then who the fuck knows what will happen. Your guess is as good as mine.\n\nSomewhat relatedly, the following has made its rounds on HN and Lobsters more than once: Actually Portable Executables. For people who haven’t seen it, this is basically a technique to create a “polyglot” x86 binary that runs on Unix, DOS/Windows, Mac, bare metal, and so forth. On Unix, this works by exploiting an ancient misfeature that has evidently been codified in bloody POSIX. Here’s a longish quote from the post:\n\nOne day, while studying old code, I found out that it’s possible to encode Windows Portable Executable files as a UNIX Sixth Edition shell script, due to the fact that the Thompson Shell didn’t use a shebang line. Once I realized it’s possible to create a synthesis of the binary formats being used by Unix, Windows, and MacOS, I couldn’t resist the temptation of making it a reality, since it means that high-performance native code can be almost as pain-free as web apps. Here’s how it works:\n\nThere are already plenty of ways to use the wrong interpreter on the wrong code. This one would be easy to prevent. But nope, likely not gonna happen, at least on POSIX systems.",
"sig": "2f6e60aa7df7596019dea4f77f3ca82d8d532d3030039cfe664bb769ef1070563ee99ba45e87fd07661df91277db4eb65b9497bc051e83fe82153caa847c51c2"
}