3 ms·

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 onl

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.