Shell-Scripting ist, verglichen mit richtigen Programmiersprachen wie Python oder Ruby, ein heilloses Gefrickel. Die Syntax ist absurd, es gibt Stolperfallen ohne Ende, es ist lächerlich ineffizient und die Möglichkeiten sind extrem beschränkt. Wieso sollte sich ein vernünftiger Mensch so einen Mist antun wollen?
Hast Du mal *.bat oder *.cmd Dateien gesehen - es ist noch totaler lächerlicher, noch mehr ineffizient und die Möglichkeiten sind super extremer beschränkt - aber es ist alles was Windows "out of the box" hat/versteht - Shell-Scripting ist alles was Unix "out of the box" kann (but a whole lot more than bat), darum tun Admins sich das an!
"aber es ist alles was Windows "out of the box" hat/versteht"
Nö
Windows bietet schon seit vielen Jahren alternativen, wie den Windows Scripting Host, und inzwischen fest auch .Net und die PowerShell. Wer nur die Windows-Batchfiles kennt, hat schlicht 10 Jahre gepennt.
Von trsrijseojtroi am Mi, 8. September 2010 um 05:36 #
Bei Windows 7 sind sowohl .NET 3.5 als auch Powershell 2.0 vorinstalliert... Übrigens gab es schon zu Windows 95-Zeiten den Windows Scripting Host (seit 98/2000 vorinstalliert), mit dem man in UNIX-Manier Skripte in VB oder JS schreiben kann. Bedenkt man, dass man viele Windows-Programme mit VB automatisieren kann, ist es alarmierend zu sehen, wie wenig das genutzt wird...
"dass man viele Windows-Programme mit VB automatisieren kann, ist es alarmierend zu sehen, wie wenig das genutzt wird..."
Hat wohl wegen der Viren einen schlechten Ruf bekommen. Bei Apple ist das mit AppleScript anders, das wird oft genutzt. Ist aber auch etwas mächtiger, da mehr Anwendungen dort integriert sind.
"dass man viele Windows-Programme mit VB automatisieren kann, ist es alarmierend zu sehen, wie wenig das genutzt wird..."
Hat wohl wegen der Viren einen schlechten Ruf bekommen. Bei Apple ist das mit AppleScript anders, das wird oft genutzt. Ist aber auch etwas mächtiger, da mehr Anwendungen dort integriert sind.
Python und Ruby sind, wenn man nicht jedes Feature nutzt, leichter als die Shellscripte zu schreiben. Python ist für das einfache erlernen entwickelt worden. Und gut darin.
Es gibt Admins, die keine Ahnung von ruby haben. Deshalb tun wir uns die shell an. Einen Admin, der sich das nicht in einer Woche aneignen kann, würde ich nicht einstellen.
Die shell hat nie der Anspruch gehabt eine Programmiersprache zu sein, auch wenn Elementen einer Hochsprache enthalten sind. Die shell dient primär zur Aufruf von Kommandos (Programme). Sie stellt effektive Möglichkeit wiederkehrende Aufgaben zu automatisieren. Für administrative Aufgaben ist sie das einzige was mit Sicherheit funktioniert, eine Bournes kompatible Shell gehört zur Grundausstattung jeder System. Python, Perl, Ruby und so weiter sind Extras die nicht unbedingt vorhanden sind. In Python wäre der Entsprechung von z.B. "cat Datei | more" mit ein höheren Aufwand verbunden. Dieses Beispiel ist zwar ein wenig blöd (more Datei tut das gleiches), sollte aber aufzeigen, dass die Ziele der shell und eine Programmiersprache unterschiedlich sind, auch wenn man mit beide zu ähnliche Ergebnisse kommt.
Und nicht zu vergessen, dass z.B. grep derart ausgereift ist und daher eine Performance bietet, die viele Coder mit ihren schnellen Scripten und wenig überdachten Algos nicht erreichen...
Man sollte in jeder Sprache die passenden Module / Funktionen kennen. Wer in Python ein grep selbst implementiert, ist da selber Schuld.
Ich finde Shell-Scripte in gewissem Umfang ok. Spätestens wenn man sich viele Funktionen schreibt und versucht komplexere Datentypen zu emulieren ist man da am Ende angekommen und sollte auf eine modernere Sprache wechseln, die zu mehr als reinen Batch-Jobs zu gebrauchen ist.
Du kannst unter Python alles nutzen, was dir auch ein Bash-Script bringt, nur eben auch noch deutlich mehr. Das ist ja das gute daran.
Das Problem mit Shellscripten ist, das sie oft zu komplex werden, weil die meisten nicht den Sprung auf die nächst höhere Stufe schaffen. Einfache Shellscripte sind absolut ok, dafür ist es super, aber leider gibt es oftmals Monsterscripte mit hunderten Zeilen, die am Ende kaum noch lesbar sind, die aber in moderneren Scriptsprachen leicht um 80% geschrumpt werden könnten.
Die Angst vor Python und co. ist oft groß, obwohl es dafür kaum einen echten Grund gibt.
Du kannst unter Python alles nutzen, Vor allem wenn Python nicht vorhanden ist. aber leider gibt es oftmals Monsterscripte ... Unter einer shell kann auch sauber programmiert werden. Manches geht aber in ein shell script nur umständlich oder überhaupt nicht. Sh ist, wie bereits geschrieben, für manche Aufgaben das beste für andere sind Progammiersprache prädestiniert. Bitte Äpfel nicht mit Birne vergleichen.
Die shell hat nie der Anspruch gehabt eine Programmiersprache zu sein, auch wenn Elementen einer Hochsprache enthalten sind. Welchen Anspruch die Shell hatte oder nicht hatte, ist mir herzlich egal. Fakt ist, dass es als Programmiersprache genutzt wird, und dass man es meiden sollte, wo immer es möglich ist. Für administrative Aufgaben ist sie das einzige was mit Sicherheit funktioniert, eine Bournes kompatible Shell gehört zur Grundausstattung jeder System. Python, Perl, Ruby und so weiter sind Extras die nicht unbedingt vorhanden sind. Debian (hier mal stellvertretend für zahlreiche weitere Linux-Distris), HP-UX, AIX, IRIX, Solaris, FreeBSD, OpenBSD, Mac OS X, Tru64 und z/OS bringen allesamt einen Perl-Interpreter mit, damit gehört es zur Grundausstattung aller praktisch relevanten Systeme und ist heutzutage alles andere als ein "Extra".
Zudem hat Larry Wall den Nagel auf den Kopf getroffen, als er sagte:
It's easier to port a shell than a shell script.
Bourne-Shells verhalten sich auf jedem System ein bisschen anders, ganz zu schweigen von den hunderten Tools (sed, awk, grep usw.), die auch je nach System anders funktionieren. In der Praxis ist Portabilität damit nicht gegeben.
>> In der Praxis ist Portabilität damit nicht gegeben.
Doch. Dafür gibt es Standards wie POSIX. In allen Manpages, die ich bislang gelesen habe, stand: "This is a GNU Extension", um den Programmierer vor Inkompatibilität zu warnen. Zudem kann man den Shebang anpassen, falls das Skript bspw. eh nur für die Bash ist. Außerdem gibt es das Skript "check-bashishms" (zumindest in Debian), welches vor Bash-Only-Zeugs warnt. Wer es da noch schafft, inkompatible Shell-Skripte zu erstellen, wenn sie portabel sein sollen, ist selbst schuld. Manchmal soll ein Skript bloß auf GNU + Bash laufen, das ist aber wieder etwas anderes.
>> It's easier to port a shell than a shell script.
Dem kann ich nur wiedersprechen. Shell-Skripte zu portieren ist nicht sonderlich schwer. Alles, was man kennen muss sind die Eigenheiten der Ursprungsshell im Vergleich zum Standard (RTFM) und die Standards (das setze ich voraus, wenn jemand mit Shell-Skripten arbeitet), der Rest ist Handwerk. Die Shells die heute verbreitet sind (Bash, ZSH, usw.) sind syntaktisch zu 80% zueinander kompatiblel, der Rest ist keine Kunst. Zum portieren einer Shell musst du zusätzlich noch C beherschen und u. U. die Charateristika des darunterliegenden Systems kennen.
Von daher entbehrt - für mich - dieses Zitat jeder Logik.
Er meinte - zu Recht - mit der Portabilität das Programm-Wirrwarr.
Der BSD grep hat ein anderes Verhalten als der GNU grep. Und je mehr man externe Programme einbindet, die als Standard bei jedem System installiert aber unterschiedlich implementiert sind, desto mehr muss man insgesamt mit einem anderen Verhalten rechnen.
Das Zitat ging wohl ebenfalls in die gleiche Richtung. Ein Shellskript, welches nur sh Syntax benutzt, ist hier nicht gemeint. Ein Skript, welches mehrere externe Programme einbindet, die unterschiedlich implementiert sind, zu portieren, gleicht der Portierung jeder der verwendeten Programme im Skript. Und da ist: It's easier to port a shell than a shell script.
>> Der BSD grep hat ein anderes Verhalten als der GNU grep
Richtig. Trotzdem sind sie zu 80% kompatibel. Die anderen 20% sind in der manpage als nicht-standard Erweiterung deklariert (This is a GNU Extension). Wenn ich GNU-Erweiterungen benutze, dann weiß ich vorher, dass es mit BSD-grep nicht läuft.
>> Und da ist: It's easier to port a shell than a shell script.
Die Portierung von GNU auf BSD ist immer noch viel einfacher als einen ganzen Interpreter zu portieren und benötigt auch nur einen Bruchteil der Zeit, auch wenn ihr mir diesen Satz jetzt noch dreißig Mal vorkaut. Schon mal was von Metapher gehört? Der Aufwand einen Interpreter zu portieren IST größer als der ein Skript zu portieren.
Trotzdem sind sie zu 80% kompatibel. Die anderen 20% sind in der manpage als nicht-standard Erweiterung deklariert (This is a GNU Extension).
Nö, es ist gerade umgekehrt: Die POSIX-Optionen sind explizit gekennzeichnet, während die GNU-Erweiterungen nicht kommentiert sind.
Und, auf die Gefahr hin, mich zu wiederholen: Die GNU-Erweiterungen gibt es nicht zum Spaß. Die von POSIX vorgeschriebenen Tools reichen eben oft nicht aus, und dann ist man mit Perl in der Praxis besser dran als mit Shell-Schrott.
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.
Shell-Scripting ist, verglichen mit richtigen Programmiersprachen wie Python oder Ruby, ein heilloses Gefrickel. Die Syntax ist absurd, es gibt Stolperfallen ohne Ende, es ist lächerlich ineffizient und die Möglichkeiten sind extrem beschränkt. Wieso sollte sich ein vernünftiger Mensch so einen Mist antun wollen?
Hast Du mal *.bat oder *.cmd Dateien gesehen - es ist noch totaler lächerlicher, noch mehr ineffizient und die Möglichkeiten sind super extremer beschränkt - aber es ist alles was Windows "out of the box" hat/versteht - Shell-Scripting ist alles was Unix "out of the box" kann (but a whole lot more than bat), darum tun Admins sich das an!
"aber es ist alles was Windows "out of the box" hat/versteht"
Nö
Windows bietet schon seit vielen Jahren alternativen, wie den Windows Scripting Host, und inzwischen fest auch .Net und die PowerShell.
Wer nur die Windows-Batchfiles kennt, hat schlicht 10 Jahre gepennt.
.Net und PowerShell sind nicht out-of-the-box dabei.
Du bist nicht auf aktuellem Stand.
Also auf dem Windows 7, dass ich zu Gunsten von GNU/Linux gelöscht hatte, war beides nicht mit dabei.
Aber wahrscheinlich hatte ich die falsche von den 350 verschiedenen Ultimate-Super-Giga-Editionen.
"war beides nicht mit dabei."
Doch, ganz sicher. Du hast nur nicht richtig geschaut.
Bei Windows 7 sind sie dabei.
Und selbst wenn nicht, der Windows Scripting Host, der auch nicht übel ist, war schon bei XP dabei.
Der WSH ist laut Internerquelle mit W sogar seit Windows 98 dabei. Natürlich in einer frühen Version.
Bei Windows 7 sind sowohl .NET 3.5 als auch Powershell 2.0 vorinstalliert... Übrigens gab es schon zu Windows 95-Zeiten den Windows Scripting Host (seit 98/2000 vorinstalliert), mit dem man in UNIX-Manier Skripte in VB oder JS schreiben kann. Bedenkt man, dass man viele Windows-Programme mit VB automatisieren kann, ist es alarmierend zu sehen, wie wenig das genutzt wird...
"dass man viele Windows-Programme mit VB automatisieren kann, ist es alarmierend zu sehen, wie wenig das genutzt wird..."
Hat wohl wegen der Viren einen schlechten Ruf bekommen. Bei Apple ist das mit AppleScript anders, das wird oft genutzt. Ist aber auch etwas mächtiger, da mehr Anwendungen dort integriert sind.
"dass man viele Windows-Programme mit VB automatisieren kann, ist es alarmierend zu sehen, wie wenig das genutzt wird..."
Hat wohl wegen der Viren einen schlechten Ruf bekommen. Bei Apple ist das mit AppleScript anders, das wird oft genutzt. Ist aber auch etwas mächtiger, da mehr Anwendungen dort integriert sind.
Es gibt Admins, die keine Ahnung von ruby haben. Deshalb tun wir uns die shell an.
Ruby ist Aufgabe unserer Programmierabteilung...
MfG Schmatke
Python und Ruby sind, wenn man nicht jedes Feature nutzt, leichter als die Shellscripte zu schreiben. Python ist für das einfache erlernen entwickelt worden. Und gut darin.
Es gibt Admins, die keine Ahnung von ruby haben. Deshalb tun wir uns die shell an.
Einen Admin, der sich das nicht in einer Woche aneignen kann, würde ich nicht einstellen.
Die shell hat nie der Anspruch gehabt eine Programmiersprache zu sein, auch wenn Elementen einer Hochsprache enthalten sind. Die shell dient primär zur Aufruf von Kommandos (Programme). Sie stellt effektive Möglichkeit wiederkehrende Aufgaben zu automatisieren. Für administrative Aufgaben ist sie das einzige was mit Sicherheit funktioniert, eine Bournes kompatible Shell gehört zur Grundausstattung jeder System. Python, Perl, Ruby und so weiter sind Extras die nicht unbedingt vorhanden sind. In Python wäre der Entsprechung von z.B. "cat Datei | more" mit ein höheren Aufwand verbunden. Dieses Beispiel ist zwar ein wenig blöd (more Datei tut das gleiches), sollte aber aufzeigen, dass die Ziele der shell und eine Programmiersprache unterschiedlich sind, auch wenn man mit beide zu ähnliche Ergebnisse kommt.
+1
Und nicht zu vergessen, dass z.B. grep derart ausgereift ist und daher eine Performance bietet, die viele Coder mit ihren schnellen Scripten und wenig überdachten Algos nicht erreichen...
Man sollte in jeder Sprache die passenden Module / Funktionen kennen. Wer in Python ein grep selbst implementiert, ist da selber Schuld.
Ich finde Shell-Scripte in gewissem Umfang ok. Spätestens wenn man sich viele Funktionen schreibt und versucht komplexere Datentypen zu emulieren ist man da am Ende angekommen und sollte auf eine modernere Sprache wechseln, die zu mehr als reinen Batch-Jobs zu gebrauchen ist.
Du kannst unter Python alles nutzen, was dir auch ein Bash-Script bringt, nur eben auch noch deutlich mehr.
Das ist ja das gute daran.
Das Problem mit Shellscripten ist, das sie oft zu komplex werden, weil die meisten nicht den Sprung auf die nächst höhere Stufe schaffen. Einfache Shellscripte sind absolut ok, dafür ist es super, aber leider gibt es oftmals Monsterscripte mit hunderten Zeilen, die am Ende kaum noch lesbar sind, die aber in moderneren Scriptsprachen leicht um 80% geschrumpt werden könnten.
Die Angst vor Python und co. ist oft groß, obwohl es dafür kaum einen echten Grund gibt.
Du kannst unter Python alles nutzen,
Vor allem wenn Python nicht vorhanden ist.
aber leider gibt es oftmals Monsterscripte ...
Unter einer shell kann auch sauber programmiert werden.
Manches geht aber in ein shell script nur umständlich oder überhaupt nicht.
Sh ist, wie bereits geschrieben, für manche Aufgaben das beste für andere sind Progammiersprache prädestiniert.
Bitte Äpfel nicht mit Birne vergleichen.
Die shell hat nie der Anspruch gehabt eine Programmiersprache zu sein, auch wenn Elementen einer Hochsprache enthalten sind.
Welchen Anspruch die Shell hatte oder nicht hatte, ist mir herzlich egal. Fakt ist, dass es als Programmiersprache genutzt wird, und dass man es meiden sollte, wo immer es möglich ist.
Für administrative Aufgaben ist sie das einzige was mit Sicherheit funktioniert, eine Bournes kompatible Shell gehört zur Grundausstattung jeder System. Python, Perl, Ruby und so weiter sind Extras die nicht unbedingt vorhanden sind.
Debian (hier mal stellvertretend für zahlreiche weitere Linux-Distris), HP-UX, AIX, IRIX, Solaris, FreeBSD, OpenBSD, Mac OS X, Tru64 und z/OS bringen allesamt einen Perl-Interpreter mit, damit gehört es zur Grundausstattung aller praktisch relevanten Systeme und ist heutzutage alles andere als ein "Extra".
Zudem hat Larry Wall den Nagel auf den Kopf getroffen, als er sagte:
Bourne-Shells verhalten sich auf jedem System ein bisschen anders, ganz zu schweigen von den hunderten Tools (sed, awk, grep usw.), die auch je nach System anders funktionieren. In der Praxis ist Portabilität damit nicht gegeben.>> In der Praxis ist Portabilität damit nicht gegeben.
Doch. Dafür gibt es Standards wie POSIX. In allen Manpages, die ich bislang gelesen habe, stand: "This is a GNU Extension", um den Programmierer vor Inkompatibilität zu warnen. Zudem kann man den Shebang anpassen, falls das Skript bspw. eh nur für die Bash ist. Außerdem gibt es das Skript "check-bashishms" (zumindest in Debian), welches vor Bash-Only-Zeugs warnt. Wer es da noch schafft, inkompatible Shell-Skripte zu erstellen, wenn sie portabel sein sollen, ist selbst schuld. Manchmal soll ein Skript bloß auf GNU + Bash laufen, das ist aber wieder etwas anderes.
>> It's easier to port a shell than a shell script.
Dem kann ich nur wiedersprechen. Shell-Skripte zu portieren ist nicht sonderlich schwer. Alles, was man kennen muss sind die Eigenheiten der Ursprungsshell im Vergleich zum Standard (RTFM) und die Standards (das setze ich voraus, wenn jemand mit Shell-Skripten arbeitet), der Rest ist Handwerk. Die Shells die heute verbreitet sind (Bash, ZSH, usw.) sind syntaktisch zu 80% zueinander kompatiblel, der Rest ist keine Kunst. Zum portieren einer Shell musst du zusätzlich noch C beherschen und u. U. die Charateristika des darunterliegenden Systems kennen.
Von daher entbehrt - für mich - dieses Zitat jeder Logik.
Zur Logik:
Er meinte - zu Recht - mit der Portabilität das Programm-Wirrwarr.
Der BSD grep hat ein anderes Verhalten als der GNU grep. Und je mehr man externe Programme einbindet, die als Standard bei jedem System installiert aber unterschiedlich implementiert sind, desto mehr muss man insgesamt mit einem anderen Verhalten rechnen.
Das Zitat ging wohl ebenfalls in die gleiche Richtung.
Ein Shellskript, welches nur sh Syntax benutzt, ist hier nicht gemeint. Ein Skript, welches mehrere externe Programme einbindet, die unterschiedlich implementiert sind, zu portieren, gleicht der Portierung jeder der verwendeten Programme im Skript. Und da ist: It's easier to port a shell than a shell script.
>> Der BSD grep hat ein anderes Verhalten als der GNU grep
Richtig. Trotzdem sind sie zu 80% kompatibel. Die anderen 20% sind in der manpage als nicht-standard Erweiterung deklariert (This is a GNU Extension). Wenn ich GNU-Erweiterungen benutze, dann weiß ich vorher, dass es mit BSD-grep nicht läuft.
>> Und da ist: It's easier to port a shell than a shell script.
Die Portierung von GNU auf BSD ist immer noch viel einfacher als einen ganzen Interpreter zu portieren und benötigt auch nur einen Bruchteil der Zeit, auch wenn ihr mir diesen Satz jetzt noch dreißig Mal vorkaut. Schon mal was von Metapher gehört? Der Aufwand einen Interpreter zu portieren IST größer als der ein Skript zu portieren.
Und, auf die Gefahr hin, mich zu wiederholen: Die GNU-Erweiterungen gibt es nicht zum Spaß. Die von POSIX vorgeschriebenen Tools reichen eben oft nicht aus, und dann ist man mit Perl in der Praxis besser dran als mit Shell-Schrott.
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
bis wann läuft das gewinnspiel?
Teilnahmeschluss ist der Mo, 13. September 2010, 23:59 Uhr
MfG Schmatke