> There appears to be one piece of software which is misinterpreting guidance of this, and trying to depend upon embedded NUL.
Curious what this is
Curious what this is
> It remains possible to put arbitrary bytes AFTER the parts of the shell script that get parsed & executed (like some Solaris patch files do). But you can't put arbirary bytes in the middle,
4d 5a 71 46 70 44 3d 27 0a 00 00 10 00 f8 00 00 |MZqFpD='........|
There are already nul bytes here, and there are a lot more before the single quote gets closed at offset 0x200.
>>> s[:11]
b"MZqFpD='\n\n\x00"
Yeah I found it here
https://news.ycombinator.com/item?id=41030960
2019 bug - https://austingroupbugs.net/view.php?id=1250
> This is an idea whose time has come; POSIX even changed their rules about binary in shell scripts specifically to let us do it.
FWIW I agree with this OpenBSD change, which says more pointedly
All the shells are written in C, and majority of them use C strings for everything, which means they cannot embed a NUL, so this is not surprising. It is quite unbelievable there are people trying to rewrite history on a lark, and expecting the world to follow alone.
i.e. it's not worth it to change a bunch of old code in order to allow making code more esoteric.
We want systems code to be more predictable, reliable, and less esoteric ... not more esoteric
I'd seen this quote around. The fact that the standards were changed to allow it never struck me as a good indication that it should be relied upon. It seems rather backwards of how these standards work.
I got flamed on HN once for saying cosmopolitan libc shouldn't be used for production because it relies on weird behaviors and implementation quirks that aren't really an ABI.
From the 'changed their rules' link, the 'Desired Action' is to add this text: "The input file may be of any type, but the initial portion of the file intended to be parsed according to the shell grammar [..] shall not contain the NUL character."
This handles things like shar archives where you have a shell script at the beginning, then an exit command, then binary gunk.
But Cosmopolitan binaries are not just shell scripts with binary. They're hybrids of shell script and DOS executable. And apparently this requires putting nul bytes right near the beginning (see my other comment, https://news.ycombinator.com/item?id=41640331), in the "portion [..] intended to be parsed according to the shell grammar". Which explicitly violates the new text.
I can understand why this hack is needed for what Cosmopolitan is trying to accomplish, but it makes no sense to claim POSIX blessed it.
If it did, then would be a sign that the POSIX process is not working well
Because POSIX is supposed to be descriptive of what exists, not prescribe new behavior
Well, it can be argued that ape already existed when that POSIX change was written :)
Everything is working as intended. Nothing to see here. Move along. Move along.
https://news.ycombinator.com/item?id=41627889
APE was mentioned and some interesting tidbits in the GitHub link provided in the HN comment above.