Comment by skissane

1 year ago

> In some ways, Apple's adherence to UNIX specifications probably makes macOS less useful for you. For example, I wish that grep on macOS was closer to GNU grep. When I look up commands online, I often find answers based on the GNU implementations. Those often work on macOS, but sometimes don't (or have subtly different behavior) because macOS is adhering to the UNIX specification rather than to what those utilities do on the vast majority of systems out there.

UNIX certification is not the reason why macOS utilities are missing options compared to GNU - UNIX standards say you have to have certain options which work a certain way, they don’t prohibit adding additional options as vendor extensions. The reason is that Apple’s investment in improving these tools is minimal because it is a low priority for them, and because people who get annoyed by this often just end up installing the GNU tools anyway (using Homebrew or MacPorts)

In fact, GNU/Linux systems have been certified as UNIX in the past, by a couple of different Chinese vendors (Inspur K-UX, Huawei EulerOS)-which shows use of the GNU tools is no inherent obstacle to certification. The reason these vendors stopped, I suspect, is the money it was making them was smaller than the certification costs and UNIX trademark license fee

17 comments

skissane

Reply
jchw  1 year ago

Pretty sure GNU coreutils really does intentionally deviate from POSIX compliance in a handful of places, otherwise POSIXLY_CORRECT wouldn't exist. That said you're probably right, though I also suspect dealing with GPL licensing is another major reason they don't bother with things like GNU coreutils. (Obviously they definitely wouldn't have done it after coreutils switched to GPLv3, but I'm sure even before then they would've greatly preferred permissively-licensed software.)

  • chasil  1 year ago

    There is some subtlety that you are missing here.

    Outside of coreutils, let's consider bash and ksh88.

    The two have differing behavior in several areas (coprocesses, alias handling, final pipeline fork, etc.), but this divergence in behavior happened before POSIX.2 and the standardization of the POSIX shell, which is largely a subset of ksh88.

    The gist is that activating a mode for POSIX compliance will generally remove functionality, because the standardization happened a decade after development began, and the standards themselves were excessively conservative in adherence to System V.

    I've seen that useful GNU extensions are generally adopted by BSD, but much more slowly by POSIX.

    That does not serve UNIX well. Someone should challenge the Austin Group for effective control of UNIX standardization.

    • jchw  1 year ago

      AFAIK, enabling POSIXLY_CORRECT doesn't get rid of any functionality. It changes some very subtle behaviors, such as the way certain argument parsing edge cases would be handled.

      Anyway, I think this is somewhat a non-issue: even if bash doesn't fully comply with POSIX standards by default, it should still be possible to be POSIX compliant by delivering a compliant shell in the right place. Though this does make me wonder if there's anything in POSIX that would require the user's default login shell to be POSIX-compliant, Bourne shell compatible. Probably not, right? After all, macOS had been using bash for ages with no issues complying.

      8 replies →

  • skissane  1 year ago

    > Pretty sure GNU coreutils really does intentionally deviate from POSIX compliance in a handful of places, otherwise POSIXLY_CORRECT wouldn't exist.

    To get UNIX certification, you can just patch it to make POSIXLY_CORRECT=1 the default.

    Or even don’t patch the utilities, and just patch /etc/profile to set POSIXLY_CORRECT=1 globally.

    UNIX certification requires that the system have a mode of operation available which passes the test suite; the existence of config settings which if changed from their defaults produce standards violations is not in itself a standards violation.

    • jchw  1 year ago

      The point is that the default build of GNU coreutils in the default configuration is not POSIX compliant, not that it can't be made to be POSIX compliant. Obviously it can be done, otherwise that environment variable would not exist.

pornel  1 year ago

Apple got spooked by GPL v3 anti-tivoization clauses and stopped updating GNU tools in 2007.

macOS still has a bunch of GNU tools, but they appear to be incompatible with GNU tools used everywhere else, because they're so outdated.

  • wkat4242  1 year ago

    And Apple is doing a lot of Tivoization these days. They're not yet actually stopping apps that they haven't "notarized" but they're not making it easier. One of the many reasons I left the Mac platform, both private and at work. The other reason was more and more reliance on the iCloud platform for new features (many of its services don't work on other OSes like Windows and Linux - I use all those too)

    The problem with the old tools is that I don't have admin rights at work so it's not easy to install coreutils. Or even homebrew.

    I can understand why they did it though. Too many tools these days advocate just piping some curl into a root shell which is pretty insane. Homebrew does this too.