I get the feeling that POSIX compliance is not always a priority. For instance, I once pointed out that the ed(1) l(ist) command doesn’t print a ‘$’ at the end of each line. I don’t even qualify as a programming enthusiast, but it seems to me that this should be a simple enhancement. A poor fellow thought Theo approved of his fix (so did I, to be honest), but it was just a rebuke in his usual style, without further explanation [1].
Since there’s a big overlap between crustaceans and OpenBSD developers, I’d be grateful to learn of the rationale for not touching this. Maybe the old-styled output for the list command is used in essential system scripts?
I’d be grateful to learn of the rationale for not touching this.
Perhaps because the person touching it didn’t bother trying to find out what it was backwards compatible with, and didn’t analyze why the code was there in the first place?
If it’s unclear why code is there, clear that up before deleting it.
Thanks, that’s great news! I don’t currently have access to an OpenBSD system, to be honest. Still, that means two and a half years to comply with POSIX over a one-character fix, so again I feel compliance is not always a priority.
It is not always a priority. Why should posix compliance take precedence over everything else?
Each such question is generally being dealt with on a case-by-case basis.
Implementing whatever posix comes up with is not a stated goal of the OpenBSD project.
And adding whatever OpenBSD invents is obviously not a stated goal of posix either. As one example, see arc4random(3).
A quick check of posix suggests PWD should always be exported.
I get the feeling that POSIX compliance is not always a priority. For instance, I once pointed out that the ed(1) l(ist) command doesn’t print a ‘$’ at the end of each line. I don’t even qualify as a programming enthusiast, but it seems to me that this should be a simple enhancement. A poor fellow thought Theo approved of his fix (so did I, to be honest), but it was just a rebuke in his usual style, without further explanation [1].
Since there’s a big overlap between crustaceans and OpenBSD developers, I’d be grateful to learn of the rationale for not touching this. Maybe the old-styled output for the list command is used in essential system scripts?
[1] https://marc.info/?l=openbsd-misc&m=141679790528805&w=2
Perhaps because the person touching it didn’t bother trying to find out what it was backwards compatible with, and didn’t analyze why the code was there in the first place?
If it’s unclear why code is there, clear that up before deleting it.
[Comment removed by author]
You should’ve checked before posting this very example - it has been fixed a month ago :^)
Thanks, that’s great news! I don’t currently have access to an OpenBSD system, to be honest. Still, that means two and a half years to comply with POSIX over a one-character fix, so again I feel compliance is not always a priority.
It is not always a priority. Why should posix compliance take precedence over everything else? Each such question is generally being dealt with on a case-by-case basis.
Implementing whatever posix comes up with is not a stated goal of the OpenBSD project.
And adding whatever OpenBSD invents is obviously not a stated goal of posix either. As one example, see arc4random(3).
goals.html gets confusingly close to stating just that though:
http://www.openbsd.org/goals.html
Yes, posix compliance is a goal. But that does not mean it’s at the highest priority of all the things the project does.
We all agree it’s not the highest priority, and probably OpenBSD would not be what it is if it were. Thanks for contributing to such a fine project.