Tja, nur leider sind diese oft vage. Beispielsweise kann man mit set -e veranlassen, dass eine Shell sich beendet, wenn ein Kommando nicht 0 zurück gibt. Aber was, wenn das betreffende Kommando in runden Klammern steht, was gemäß POSIX eine Subshell startet? Wird dann nur der Block in runden Klammern (also die Subshell) beendet, oder die gesamte Shell? Die Bash beendet die Subshell, die Bourne-Shell beendet sich komplett, und keiner weiß, was nun richtig ist. Geschweige denn, dass sich irgend jemand solcher Sachen bewusst wäre.
Ferner halten sich genug Systeme da draußen auch nicht an den Standard, oft auch, weil er keinen Sinn ergibt (Beispiel: die meisten GNU-Utilities geben Größen in 1024-Byte-Blöcken (KiB) an, während POSIX blödsinnigerweise meist 512-Byte-Blöcke vorschreibt) oder haben Bugs (immer gern gesehen: "long lines will be silently truncated").
Zudem ist es ja auch nicht so, dass die GNU-Leute sich die Erweiterungen zum Spaß ausgedacht haben, sondern weil die eben benötigt werden, um bestimmte Sachen zu machen. Wenn man also ein portables Shell-Script schreiben will, handelt man sich andere Probleme und Beschränkungen ein.
In allen Manpages, die ich bislang gelesen habe, stand: "This is a GNU Extension", um den Programmierer vor Inkompatibilität zu warnen.
Bei GNU ls ist das z. B. nicht der Fall. Und bei einigen anderen Tools hat man sich für den umgekehrten Ansatz entschieden und dokumentiert, welche der Optionen POSIX entsprechen (statt zu dokumentieren, welche das nicht tun).
Und selbst, wenn es theoretisch möglich ist, portable Shell-Scripte zu schreiben, so macht es trotzdem keiner, weil es viel zu aufwendig ist. Kein Mensch prüft wirklich für jede Option und jedes Kommando, ob POSIX sie vorschreibt oder nicht. Bei Perl stehen die Chancen gut, dass ein Script auf verschiedenen Plattformen einfach so funktioniert.
Von daher entbehrt - für mich - dieses Zitat jeder Logik.
Man muss schon ziemlich dämlich sein, um so ein Bonmot wörtlich zu nehmen.
Ferner halten sich genug Systeme da draußen auch nicht an den Standard, oft auch, weil er keinen Sinn ergibt (Beispiel: die meisten GNU-Utilities geben Größen in 1024-Byte-Blöcken (KiB) an, während POSIX blödsinnigerweise meist 512-Byte-Blöcke vorschreibt) oder haben Bugs (immer gern gesehen: "long lines will be silently truncated").
Zudem ist es ja auch nicht so, dass die GNU-Leute sich die Erweiterungen zum Spaß ausgedacht haben, sondern weil die eben benötigt werden, um bestimmte Sachen zu machen. Wenn man also ein portables Shell-Script schreiben will, handelt man sich andere Probleme und Beschränkungen ein.
Bei GNU ls ist das z. B. nicht der Fall. Und bei einigen anderen Tools hat man sich für den umgekehrten Ansatz entschieden und dokumentiert, welche der Optionen POSIX entsprechen (statt zu dokumentieren, welche das nicht tun).Und selbst, wenn es theoretisch möglich ist, portable Shell-Scripte zu schreiben, so macht es trotzdem keiner, weil es viel zu aufwendig ist. Kein Mensch prüft wirklich für jede Option und jedes Kommando, ob POSIX sie vorschreibt oder nicht. Bei Perl stehen die Chancen gut, dass ein Script auf verschiedenen Plattformen einfach so funktioniert.
Man muss schon ziemlich dämlich sein, um so ein Bonmot wörtlich zu nehmen.Ich habe es "ernst" genommen