3 ms·

The only operating systems that are certified to conform to POSIX are old Unix operating systems. GNU has always been non-POSIX. And honestly, a POSIX implement

The only operating systems that are certified to conform to POSIX are old Unix operating systems. GNU has always been non-POSIX. And honestly, a POSIX implementation would be more trouble than it's worth. The point of coreutils is to have utilities that make up the ability to write scripts for and interact with your operating system, right? Well, what operating system?? A POSIX-compliant one? Or just a mostly-POSIX-compliant one? Or one with POSIX extensions? How would your utilities know the difference? How would the OS know how to deal with these utilities? Would the user know the difference? Ultimately, each platform has quirks, and it is up to the developer to port and test their script or application to a platform and make any necessary changes. This extends to far more than just POSIX compliance.

masklinn 11y ago
That's not a question of certification or extensions, I'm talking about being able to write portable scripts. Due to the interaction between its definition and its extensions, echo is a prime example of being impossible to use portably (except in the very restricted case of only literal strings without escapes which don't start with a -). > Ultimately, each platform has quirks, and it is up to the developer to port and test their script or application to a platform and make any necessary changes. That is not humanly feasible and that's why specifications exists. You can't "port and test" your script to a platform which doesn't even exist yet, but if you follow the specification and the platform implements it (assuming it does so correctly) your scripts will run.
- peterwwillis 11y ago
  Ok, I think I understand the confusion now. You seem to be of the impression that shell scripts are like bytecode executed in a virtual machine. That is the only way I know of that you could write an application for a platform that doesn't exist and expect it to work. But even for that to work, it would need to be the same VM, and bytecode generated by & for it, or there's still no guarantee it will work. Of course, you can already write a shell script for a particular shell, distribute that shell to that system, and depend on the shell to properly execute your script [by using internal functions only]. But that defeats the whole purpose of following a standard like POSIX, or caring at all how any given platform's 'echo' program works. Bottom line, though: two independent implementations of a standard provide no guarantee they will work together. Practice over a couple decades shows this to be the case.
  - masklinn 11y ago
    > Ok, I think I understand the confusion now. You seem to be of the impression that shell scripts are like bytecode executed in a virtual machine. What in bloody hell are you talking about? > Of course, you can already write a shell script for a particular shell Which is irrelevant to my comment as that's not what portability means. > But that defeats the whole purpose of following a standard like POSIX Exactly. > Bottom line, though: two independent implementations of a standard provide no guarantee they will work together. If following a standard can't ensure your program can work on two different implementations of the standard, you don't have a standard you have decorated toilet paper. Which is more or less what the "commands and utilities" part of POSIX is.

masklinn 11y ago

That's not a question of certification or extensions, I'm talking about being able to write portable scripts. Due to the interaction between its definition and its extensions, echo is a prime example of being impossible to use portably (except in the very restricted case of only literal strings without escapes which don't start with a -). > Ultimately, each platform has quirks, and it is up to the developer to port and test their script or application to a platform and make any necessary changes. That is not humanly feasible and that's why specifications exists. You can't "port and test" your script to a platform which doesn't even exist yet, but if you follow the specification and the platform implements it (assuming it does so correctly) your scripts will run.

peterwwillis 11y ago
Ok, I think I understand the confusion now. You seem to be of the impression that shell scripts are like bytecode executed in a virtual machine. That is the only way I know of that you could write an application for a platform that doesn't exist and expect it to work. But even for that to work, it would need to be the same VM, and bytecode generated by & for it, or there's still no guarantee it will work. Of course, you can already write a shell script for a particular shell, distribute that shell to that system, and depend on the shell to properly execute your script [by using internal functions only]. But that defeats the whole purpose of following a standard like POSIX, or caring at all how any given platform's 'echo' program works. Bottom line, though: two independent implementations of a standard provide no guarantee they will work together. Practice over a couple decades shows this to be the case.
- masklinn 11y ago
  > Ok, I think I understand the confusion now. You seem to be of the impression that shell scripts are like bytecode executed in a virtual machine. What in bloody hell are you talking about? > Of course, you can already write a shell script for a particular shell Which is irrelevant to my comment as that's not what portability means. > But that defeats the whole purpose of following a standard like POSIX Exactly. > Bottom line, though: two independent implementations of a standard provide no guarantee they will work together. If following a standard can't ensure your program can work on two different implementations of the standard, you don't have a standard you have decorated toilet paper. Which is more or less what the "commands and utilities" part of POSIX is.