The README for this project still says "POSIX-approved" but there is nothing in POSIX that allows mixing commands and binary data in a shell script.
It does allow appending binary data to the end of a shell script* as long as it is guarded from being parsed as shell code by an exit, exec, etc. but that's it.
According to Justine herself[1], POSIX specifically changed their rules to allow this type of functionality[2].
The paragraph you linked to was part of it, but also this paragraph under RATIONALE[3]:
> Earlier versions of this standard required that input files to the shell be text files except that line lengths were unlimited. However, that was overly restrictive in relation to the fact that shells can parse a script without a trailing newline, and in relation to a common practice of concatenating a shell script ending with an exit or exec $command with a binary data payload to form a single-file self-extracting archive.
So Cosmopolitan indeed seems to be POSIX-approved as far as this behavior goes.
I think this isn't an entirely worthless comment, but you start off by insisting that Justine Tunney is referred to as "himself". This is either a silly mistake, or a misguided political statement.
Either way I don't think it adds to the discussion, and it's certainly going to distract people from your more interesting point that mixing binary data throughout the shell script is not permitted by the standard.
It's not an interesting point, it's a willful misinterpretation of the intent of the standard made by someone who wasn't there. The worst thing about bigots is they usually hide it and grasp for other more socially acceptable reasons to make you miserable when you're someone like me. I'm astonished you would still continue to take them seriously after they've revealed their intent and motivation.
I apologise, my interpretation was naïve. Not being familiar with the intent of the person I was responding to (directly or by experience) and not knowing the how to correctly interpret the POSIX standard, I was trying to politely re-focus the thread.
I'm lucky enough not to have to spend much time thinking about identity issues or being the target of bigotry and I suppose that was reflected in my previous comment.
Maybe it's telling that you're here making fantastic contributions for FOSS and people who are trying to bring you down are only making invalid claims about standards compliance.
I'm a big fan of yours and I'm really sorry that I contributed to that incident.
Thanks and don't worry about it. The Hacker News community has always been so welcoming and supportive to me. I'm really lucky to have had the opportunity to serve you all these last four years. If you think this was an incident, you should have seen 4chan /g/ last year. Thankfully things have been going reasonably well for me since then. Ever since publishing https://justine.lol/matmul/ I appear to have flipped the hater bit (see Paul Graham's blog) in the heads of even my most ardent detractors. So even on /g/ the disrespect has become somewhat rare these days.
I wouldn't go so far as to call their comments dehumanizing. Rude and uncalled for - absolutely. But no part of their comment proclaims that the other person doesn't deserve basic human rights.
Indeed we do. I was approaching human rights from the perspective of having a right to food, clean water and shelter, and not being threatened for your life every day. Having other people talk to you/about you the way you'd want somehow pales in comparison.
Dehumanization is the result of treating a human like they do not have equal rights and dignities.
If we decide that identity is a right within someone's control, that decision must be consistent.
If I call you "Steve," and you correct me and say, "no my name is Bob," you have exercised what I see as your right of domain over your own identity.
To preempt that right and respond with, "I prefer to call you Steve," would be absurd and rude. Also pointless. It would flout any right you have to decide who you are.
To do this in an argument or confrontation easily results in dehumanization, merely by suggesting that one person is allowed to determine their own identity while another is not.
Even if we relax this discussion to non-terminal impacts, it is quite literally optimal to just allow people this dignity.
The energy it takes to enforce every definition as your own is unsustainable. If two people cannot agree on basic definitions, there is no chance for valuable discussion anyway.
The most basic definition that exists in an argument is the parties involved. Disagreeing on that basis invalidates everything downstream.
So--if one is arguing in good faith, it costs almost nothing, and you gain a lot, to simply allow the other party to define themselves.
Definitely not my area of either pedantry or expertise, but if I read this correctly:
> The input file can be of any type, but the initial portion of the file intended to be parsed according to the shell grammar […] shall consist of characters and shall not contain the NUL character.
Then POSIX doesn’t proscribe against appending binary data at all, it just requires that binary data appears after whatever portion of the file is intended to be parsed according to the grammar… there’s nothing stating that intention can’t apply to a zero characters.
> The shell shall not enforce any line length limits.
That seems to unambiguously allow a zero-length initial portion.
> If the input file consists solely of zero or more blank lines and comments, sh shall exit with a zero exit status.
And so does that, while also making an enormous loophole for any input file that is not zero or more blank lines.
In other words it seems to me on a quick reading that a decent rules-lawyer could drive a planet through that part of the spec, as written.
POSIX is one of those standards that don't really define anything at all. Microsoft POSIX subsystem is one of the nicest examples of something that lets you tick the POSIX checkbox but does almost nothing. One of the recent posix annoyances I stumbled upon was the clock_gettime where every platform has slightly different idea how the different CLOCKs are supposed to be interpreted :)
Personally I don't find the APE part of cosmopolitan that interesting, but their own POSIX API <https://justine.lol/cosmopolitan/functions.html> which also covers windows is interesting for sure. Zig's std also offers something similar, but perhaps not as good coverage. Getting fork, mmap, and poll work on windows is not small feat.
It does allow appending binary data to the end of a shell script* as long as it is guarded from being parsed as shell code by an exit, exec, etc. but that's it.
* https://pubs.opengroup.org/onlinepubs/9799919799/utilities/s...