3 ms·

> As people have found out in the past, the real Unix API is the whole collection of behaviors and environments that Unix programs assume. It isn't just POSIX l

> As people have found out in the past, the real Unix API is the whole collection of behaviors and environments that Unix programs assume. It isn't just POSIX library calls; it's also the shell and standard utilities and files that are in known locations and standard capabilities and various other things. But... "the shell and standard utilities and files that are in known locations and standard capabilities and various other things" are also specified by POSIX. (Historically, they were the "POSIX.2" standard, and the libc/syscall library functions were in the "POSIX.1" standard, but since 1998 when POSIX became the ratification of Single Unix Specification version 2-and-later, they're all just in "POSIX".) So... yes? > Unless you intend for your program to be narrowly and specifically portable to POSIX or an even more minimal standard, it is not a bug for it to rely on portions of the broader, de facto Unix API. It's not even necessarily a bug to rely on APIs that are only there on some Unixes (for example Linux and FreeBSD), Why would any of those things be considered a "bug"? > for example, can you implement a compatible and fully capable Bourne shell using only public Unix kernel APIs, or at most public C library APIs? What other APIs does the author think that Bourne shell writers used? I feel like I'm missing some broader context for this post.

fulafel 4y ago
It's a bit ambiguous, people often mean the 90s POSIX versions when they say POSIX, even though later some rebranding/republishing of SUS happened under the POSIX name. SUS is the less ambiguous term to use I think when talking about the newer stuff.
faho 4y ago
>But... "the shell and standard utilities and files that are in known locations and standard capabilities and various other things" are also specified by POSIX. Unfortunately, it doesn't specify those known locations. It explicitly declines specifying that /bin/sh exists. https://pubs.opengroup.org/onlinepubs/9699919799/utilities/sh.html https://pubs.opengroup.org/onlinepubs/9699919799/utilities/s... says: > Applications should note that the standard PATH to the shell cannot be assumed to be either /bin/sh or /usr/bin/sh, and should be determined by interrogation of the PATH returned by getconf PATH, ensuring that the returned pathname is an absolute pathname and not a shell built-in. and it doesn't specify the location of getconf either, so you have a chicken-and-egg problem where you need the standard $PATH to find getconf to get the standard $PATH.
- vbezhenar 4y ago
  It seems to be a convention those days to use `#!/usr/bin/env sh`. At least it's a single entry point. Why can't we just write `#!sh` I never understood. Another interesting snippet from your link: "Furthermore, on systems that support executable scripts (the "#!" construct), it is recommended that applications using executable scripts install them using getconf PATH to determine the shell pathname and update the "#!" script appropriately as it is being installed (for example, with sed)." So there could be systems which does not support shebang yet claiming to be POSIX?
  - cperciva 4y ago
    Why can't we just write `#!sh` I never understood. It's because #! is handled by the kernel, but the process environment is not parsed by the kernel.
    - vbezhenar 4y ago
      Parsing PATH should not be that hard.
      - bregma 4y ago
        Sure add arbitrary user input string parsing to the privileged kernel in a place where programs are launched. The CVE database is pretty sparse as it is and could use a good churning. So, assuming the string is parsed safely and securely, does the kernel have enough semantic knowledge of paths to know which service to pass it to? Are the services guaranteed to be loaded and running at all times? Or is there an underlying architectural assumption that the kernel is a Linux-style monolith and POSIX no longer applies to micro- and nano-kernel systems?
      - cperciva 4y ago
        It isn't... now. On a PDP-11 with 40 kW of RAM, on the other hand...
- cperciva 4y ago
1vuio0pswjnm7 4y ago
"Why would any of those things be considered a "bug"?" As stated in the sentence, it would be considered a bug if the program was intended to portable. Why would it be a "feature" to write non-portable programs that only compile on some but not all UNIX-like operating systems. I can think of some reasons but none of them benefit end users who like the freedom to use a variety of UNIX-like operating systems.
- microtonal 4y ago
  Why would it be a "feature" to write non-portable programs that only compile on some but not all UNIX-like operating systems. Because you want features that require platform-specific APIs and two Unix-like systems (Linux and Darwin) have 99.9% of the marketshare among your audience? With this attitude Docker wouldn't have happened, because we'd still be bickering about a standardized API for container primitives, because someone wants to run containers on the Lites kernel on a PA-RISC machine.
  - deleted 4y ago
    [deleted]
  - pessimizer 4y ago
    That still doesn't make it a feature. If it were as easy to make it portable as not portable (which it often is not), you would choose portable.
indymike 4y ago
Context is conversations where people assume that POSIX is the spec for Unix, and some other OS is POSIX, so just re-compile already... or hey, we won't have to rewrite a lot of tooling for some other OS because we used POSIX OS... or it will just magically run because POSIX. Incidentally, a ton of GNU utilities aren't POSIX unless you set the POSIXLY_CORRECT environment variable...
shadowofneptune 4y ago
> (Historically, they were the "POSIX.2" standard, and the libc/syscall library functions were in the "POSIX.1" standard, but since 1998 when POSIX became the ratification of Single Unix Specification version 2-and-later, they're all just in "POSIX".) Ohhh, that's how Windows could be POSIX-compliant back in the 90s while not appearing like it at all. Thanks.

fulafel 4y ago

It's a bit ambiguous, people often mean the 90s POSIX versions when they say POSIX, even though later some rebranding/republishing of SUS happened under the POSIX name. SUS is the less ambiguous term to use I think when talking about the newer stuff.

faho 4y ago

>But... "the shell and standard utilities and files that are in known locations and standard capabilities and various other things" are also specified by POSIX. Unfortunately, it doesn't specify those known locations. It explicitly declines specifying that /bin/sh exists. https://pubs.opengroup.org/onlinepubs/9699919799/utilities/sh.html https://pubs.opengroup.org/onlinepubs/9699919799/utilities/s... says: > Applications should note that the standard PATH to the shell cannot be assumed to be either /bin/sh or /usr/bin/sh, and should be determined by interrogation of the PATH returned by getconf PATH, ensuring that the returned pathname is an absolute pathname and not a shell built-in. and it doesn't specify the location of getconf either, so you have a chicken-and-egg problem where you need the standard $PATH to find getconf to get the standard $PATH.

vbezhenar 4y ago
It seems to be a convention those days to use `#!/usr/bin/env sh`. At least it's a single entry point. Why can't we just write `#!sh` I never understood. Another interesting snippet from your link: "Furthermore, on systems that support executable scripts (the "#!" construct), it is recommended that applications using executable scripts install them using getconf PATH to determine the shell pathname and update the "#!" script appropriately as it is being installed (for example, with sed)." So there could be systems which does not support shebang yet claiming to be POSIX?
- cperciva 4y ago
  Why can't we just write `#!sh` I never understood. It's because #! is handled by the kernel, but the process environment is not parsed by the kernel.
  - vbezhenar 4y ago
    Parsing PATH should not be that hard.
    - bregma 4y ago
      Sure add arbitrary user input string parsing to the privileged kernel in a place where programs are launched. The CVE database is pretty sparse as it is and could use a good churning. So, assuming the string is parsed safely and securely, does the kernel have enough semantic knowledge of paths to know which service to pass it to? Are the services guaranteed to be loaded and running at all times? Or is there an underlying architectural assumption that the kernel is a Linux-style monolith and POSIX no longer applies to micro- and nano-kernel systems?
    - cperciva 4y ago
      It isn't... now. On a PDP-11 with 40 kW of RAM, on the other hand...
cperciva 4y ago

1vuio0pswjnm7 4y ago

"Why would any of those things be considered a "bug"?" As stated in the sentence, it would be considered a bug if the program was intended to portable. Why would it be a "feature" to write non-portable programs that only compile on some but not all UNIX-like operating systems. I can think of some reasons but none of them benefit end users who like the freedom to use a variety of UNIX-like operating systems.

microtonal 4y ago
Why would it be a "feature" to write non-portable programs that only compile on some but not all UNIX-like operating systems. Because you want features that require platform-specific APIs and two Unix-like systems (Linux and Darwin) have 99.9% of the marketshare among your audience? With this attitude Docker wouldn't have happened, because we'd still be bickering about a standardized API for container primitives, because someone wants to run containers on the Lites kernel on a PA-RISC machine.
- deleted 4y ago
  [deleted]
- pessimizer 4y ago
  That still doesn't make it a feature. If it were as easy to make it portable as not portable (which it often is not), you would choose portable.

indymike 4y ago

Context is conversations where people assume that POSIX is the spec for Unix, and some other OS is POSIX, so just re-compile already... or hey, we won't have to rewrite a lot of tooling for some other OS because we used POSIX OS... or it will just magically run because POSIX. Incidentally, a ton of GNU utilities aren't POSIX unless you set the POSIXLY_CORRECT environment variable...

shadowofneptune 4y ago

> (Historically, they were the "POSIX.2" standard, and the libc/syscall library functions were in the "POSIX.1" standard, but since 1998 when POSIX became the ratification of Single Unix Specification version 2-and-later, they're all just in "POSIX".) Ohhh, that's how Windows could be POSIX-compliant back in the 90s while not appearing like it at all. Thanks.