"The default shell for Void Linux is “dash” and is the “/bin/sh” of the system. It might be helpful to run chsh after logging in to change the default login shell, as dash is very limited. In shell scripts, make sure to use “#!/bin/bash” instead of “#!/bin/sh”, otherwise you may experience odd script failures due to using “dash” instead of the traditional “Bourne shell”."
Warum wird dann überhaupt Dash als Standard verwendet, wenn man in Skripten doch wieder auf Bash wechseln soll?
Ich sehe es ähnlich zum Fazit des Artikels. Allerdings kann ich das mit den "Race Conditions und Sicherheitslücken" ggü. dem vorherigen Zustand mit Bash nicht wirklich bewerten. Jedenfalls steige ich da nicht ganz dahinter.
Insgesamt finde ich schon fragwürdig, wie viel eine dash netto tatsächlich bringt. Debian bzw. die erweiterte OSS-Community kann mit ihren Ressourcen nur eine gewissen Menge an Code warten und pflegen. Für ein einzelnes Software-Projekt oder Paket mag das ja alles funktionieren. Aber im erweiterten Sinne muss geht mit einer zusätzlichen Shell mehr und noch weiter divergierenden distributionsspezifischen Shell-Skripten die Rechnung jedenfalls in die negative Richtung.
Die Vorteile einer dash spielen eigentlich nur auf wenigen Systemen wie etwa embedded ein Rolle. Dort gibt es auber auch busybox mit einer eigenen Shell (ash), die doch eigentlich gut genug ist (mksh ist noch sehr minimalistisch und wird meines Wissens nach unter Android verwendet). Unter diesen Systemen bedarf es zumeist allerdings auch einer schlankeren libc als der Implementierung von GNU. Da käme ein Debian also gar nicht mehr infrage. Deshalb kann die dash ihre Vorteile in Debian eigentlich gar nicht so gut ausspielen.
Von Verfluchtnochmal_5987108 am Mi, 19. Februar 2020 um 00:26 #
Junge entweder dein Script ist posix konform oder ein bash Script, wenn die dash reicht ist es einfach um Welten effizienter und wenn nicht schreib den richtigen shebang oben hin
Diverse Sicherheitslücken in den letzten Jahren die zB auch implizit alle shell commands des php interpreters betroffen haben waren mit einer anderen shell als /bin/sh kein Thema für den Fall irgend ein Trottel verwurstet da untrusted input
entweder dein Script ist posix konform oder ein bash Script
Keinesfalls ist jedes Shellskript, das nicht POSIX-konform ist, ein Bash-Skript. Es könnte sich ebenso gut um ein Zsh-, *ksh-, *csh- oder rc-Skript handeln. Kommt halt darauf an, in welcher Sprache es geschrieben ist.
Und in keinem der Fälle schreibt jemand mit Hirn /bin/sh oben hin[.]
Außer eben in Fällen, in denen nichts weiter vorausgesetzt werden kann als eine POSIX-kompatible Shell, die aber gleichzeitig vorausgesetzt werden muss. Dass man dann auch nur POSIX-kompatiblen Shellcode schreiben darf, erklärt sich von selbst.
Wirklich so schwer zu verstehen?
Mir war der Unterschied von POSIX sh und Bash etc. bereits klar, bevor der Artikel erschienen ist. Es ging mir, was sicherlich nicht allzu schwer zu verstehen ist, lediglich darum, dass die Behauptung, ein Shellskript sei „entweder [...] posix konform oder ein bash Script“, schlicht falsch ist.
Nicht in dem Ton, Freundchen! Wenn Sie Ihre Argumente in einer angemessenen und verständlichen Form äußern, würde ich erneut darüber nachdenken Ihnen inhaltlich zu entgegnen. So jedoch nicht!
Kleine Ergänzung aus meiner Erfahrung dazu: Das Unternehmen, für das ich arbeite, setzt auf seinen Servern sowohl diverse Pinguine als mitunter auch Teufelchen ein. Die meisten Kollegen haben einen reinen Linux-Hintergrund und haben sich so viel FreeBSD angeeignet, daß sie sich nicht verlaufen, wenn auf einem solchen System mal ein Problem auftritt, das sie lösen müssen. Allerdings versuchen sie, sich das System möglichst „linuxartig“ zu machen - mit diversen Aliasen, Symlinks und natürlich der gewohnten Shell.
Als ich privat das Betriebssystem gewechselt habe, war ich auch versucht, einfach die bekannte Bash „mitzunehmen“, habe mich dann aber dagegenentschieden und für meinen Benutzer die tcsh gewählt (schlagendes Argument: Gehört im Gegensatz zu der Bash zum Basissystem). Obwohl ich inzwischen zur Zsh weitergezogen bin, habe ich die tcsh schätzen gelernt und kann damit gut leben.
Wenn nun eine FreeBSD-Kiste mit extremer Load kämpft, weil z.B. ein Kunde einen Cronjob eingerichtet hat, der alle paar Minuten ein ziemlich ressourcenintensives Skript aufruft, das aber nicht überprüft, ob noch eine Instanz läuft (oder ähnliche solche Spielchen), muß man das ja wieder glattziehen. Die Standardshell habe ich nach dem SSH-Login selbst unter extremer Load praktisch sofort und bin (sobald sudo so nett ist und mir Rootrechte gibt) handlungsfähig. Die Kollegen, die erstmal die Bash aufrufen, sind ggf. erst Minuten (sic!) später am Start.
Grundsätzlich stimme ich zu, daß es „unter normalen Umständen“ keinen großen Unterschied macht, welche Shell nun verwendet wird. Das Problem ist aber, daß diese „normalen Umstände“ nicht das sind, womit der Admin rechnen darf.
Gegen die tcsh spricht allerdings, dass sie als csh-Abkömmling grundsätzlich nicht POSIX-kompatibel ist.
Warum daran festgehalten wird, erschließt sich mir nicht. Mir scheint, FreeBSD macht es damit unnötig kompliziert. Bei OpenBSD ist einfach für alles ksh gesetzt, soweit ich mich erinnere. Damit kommt man, meiner Erfahrung nach, auch gut zurecht, wenn man bisher kaum was anderes als Bash benutzt hat.
Bei FreeBSD wird eben viel Wert auf Stabilität, Vertrautheit und POLA (policy of least astonishment) gesetzt. Veränderungen müssen gut begründet, durchdacht, getestet und ausgereift sein, bevor sie in FreeBSD landen. Ist ein wenig wie bei Slackware, dass mittlerweile dabei ist PAM in Slackware-current und somit auch in die vermutlich nicht mehr all zu fern liegende Veröffentlichung der Version 15 zu integrieren.
Das hat große Vorteile, aber eben auch Nachteile. Letztlich ist es subjektiv, wie man diese für sich auslegt bzw. die Prioritäten setzt. Eine alternative Shell ist nur wenige Befehle auf der tcsh entfernt.
Ich denke, das dieses Phänomen einfach auf die Tatsache der Verbreitung und der Bekanntheit zurückzuführen ist. Selbst Apple ist von der tcsh als Teil der Überschneidungen mit FreeBSD dann doch auf die Bash gewechselt, solange diese noch unter GPL2 lizensiert gewesen. Die alte GPL2-Version der Bash wurde noch eine Weile mitgeschleppt bis aus lizenztechnischen Gründen irgendwann die zsh Einzug hielt.
Zu der Sache in Ihrem dritten Absatz kann ich leider nichts beitragen. Ich würde meinen, dass die Bash schon um einiges fetter ist als eine tcsh. Könnte es eventuell daran liegen, dass die tcsh aus irgendwelchen Gründen im Gegensatz zur Bash noch im Cache lag (System-Skripte / Cronjobs etc.)? Ansonsten habe ich dieses Verhalten unter großer Last schon ab und zu unter Linux erleben müssen. Im Jahr 2020 eigentlich technisch unnötig soetwas. Das geht auch gescheiter, wenn man die richtigen Designentscheidungen und Standardeinstellung durchsetzen würde.
Wie gesagt, ich denke, dass es auf den heutigen Kisten (Server und Desktops/Laptops) von der Stange aus Sicht der Hardwareressourcen keinen nennenswerten Unterschied mehr macht. Da sind andere Ressourcen wie bestehnde Kenntnis, verbreites Wissen, gute Doku und die Verbreitung einfach ausschlaggebender. Hinzu kommt aus Sicht der OSS-Projekte und -Communities, dass netto weniger Code gewartet werden muss, wenn man neben der Bash keine weitere Shell zu pflegen hat.
"The default shell for Void Linux is “dash” and is the “/bin/sh” of the system.
It might be helpful to run chsh after logging in to change the default login shell, as dash is very limited.
In shell scripts, make sure to use “#!/bin/bash” instead of “#!/bin/sh”, otherwise you may experience odd script failures due to using “dash” instead of the traditional “Bourne shell”."
Warum wird dann überhaupt Dash als Standard verwendet, wenn man in Skripten doch wieder auf Bash wechseln soll?
Ich erlaube mir auf folgenden Artikel zu verweisen, der dies erklärt.
https://www.linux-magazin.de/ausgaben/2012/12/bash-bashing/
Netter Artikel, danke.
Ich sehe es ähnlich zum Fazit des Artikels. Allerdings kann ich das mit den "Race Conditions und Sicherheitslücken" ggü. dem vorherigen Zustand mit Bash nicht wirklich bewerten. Jedenfalls steige ich da nicht ganz dahinter.
Insgesamt finde ich schon fragwürdig, wie viel eine dash netto tatsächlich bringt. Debian bzw. die erweiterte OSS-Community kann mit ihren Ressourcen nur eine gewissen Menge an Code warten und pflegen. Für ein einzelnes Software-Projekt oder Paket mag das ja alles funktionieren. Aber im erweiterten Sinne muss geht mit einer zusätzlichen Shell mehr und noch weiter divergierenden distributionsspezifischen Shell-Skripten die Rechnung jedenfalls in die negative Richtung.
Die Vorteile einer dash spielen eigentlich nur auf wenigen Systemen wie etwa embedded ein Rolle. Dort gibt es auber auch busybox mit einer eigenen Shell (ash), die doch eigentlich gut genug ist (mksh ist noch sehr minimalistisch und wird meines Wissens nach unter Android verwendet). Unter diesen Systemen bedarf es zumeist allerdings auch einer schlankeren libc als der Implementierung von GNU. Da käme ein Debian also gar nicht mehr infrage. Deshalb kann die dash ihre Vorteile in Debian eigentlich gar nicht so gut ausspielen.
Junge entweder dein Script ist posix konform oder ein bash Script, wenn die dash reicht ist es einfach um Welten effizienter und wenn nicht schreib den richtigen shebang oben hin
Diverse Sicherheitslücken in den letzten Jahren die zB auch implizit alle shell commands des php interpreters betroffen haben waren mit einer anderen shell als /bin/sh kein Thema für den Fall irgend ein Trottel verwurstet da untrusted input
Keinesfalls ist jedes Shellskript, das nicht POSIX-konform ist, ein Bash-Skript. Es könnte sich ebenso gut um ein Zsh-, *ksh-, *csh- oder rc-Skript handeln. Kommt halt darauf an, in welcher Sprache es geschrieben ist.
Und in keinem der Fälle schreibt jemand mit Hirn /bin/sh oben hin und schon ist das Thema default shell keines mehr
Wirklich so schwer zu verstehen?
Außer eben in Fällen, in denen nichts weiter vorausgesetzt werden kann als eine POSIX-kompatible Shell, die aber gleichzeitig vorausgesetzt werden muss. Dass man dann auch nur POSIX-kompatiblen Shellcode schreiben darf, erklärt sich von selbst.
Mir war der Unterschied von POSIX sh und Bash etc. bereits klar, bevor der Artikel erschienen ist. Es ging mir, was sicherlich nicht allzu schwer zu verstehen ist, lediglich darum, dass die Behauptung, ein Shellskript sei „entweder [...] posix konform oder ein bash Script“, schlicht falsch ist.
Nicht in dem Ton, Freundchen! Wenn Sie Ihre Argumente in einer angemessenen und verständlichen Form äußern, würde ich erneut darüber nachdenken Ihnen inhaltlich zu entgegnen. So jedoch nicht!
couldn't care less Freundchen
Da stellt sich doch die Frage, wieso Sie dann überhaupt kommentieren? Sonderbar...
Kleine Ergänzung aus meiner Erfahrung dazu: Das Unternehmen, für das ich arbeite, setzt auf seinen Servern sowohl diverse Pinguine als mitunter auch Teufelchen ein. Die meisten Kollegen haben einen reinen Linux-Hintergrund und haben sich so viel FreeBSD angeeignet, daß sie sich nicht verlaufen, wenn auf einem solchen System mal ein Problem auftritt, das sie lösen müssen. Allerdings versuchen sie, sich das System möglichst „linuxartig“ zu machen - mit diversen Aliasen, Symlinks und natürlich der gewohnten Shell.
Als ich privat das Betriebssystem gewechselt habe, war ich auch versucht, einfach die bekannte Bash „mitzunehmen“, habe mich dann aber dagegenentschieden und für meinen Benutzer die tcsh gewählt (schlagendes Argument: Gehört im Gegensatz zu der Bash zum Basissystem). Obwohl ich inzwischen zur Zsh weitergezogen bin, habe ich die tcsh schätzen gelernt und kann damit gut leben.
Wenn nun eine FreeBSD-Kiste mit extremer Load kämpft, weil z.B. ein Kunde einen Cronjob eingerichtet hat, der alle paar Minuten ein ziemlich ressourcenintensives Skript aufruft, das aber nicht überprüft, ob noch eine Instanz läuft (oder ähnliche solche Spielchen), muß man das ja wieder glattziehen. Die Standardshell habe ich nach dem SSH-Login selbst unter extremer Load praktisch sofort und bin (sobald sudo so nett ist und mir Rootrechte gibt) handlungsfähig. Die Kollegen, die erstmal die Bash aufrufen, sind ggf. erst Minuten (sic!) später am Start.
Grundsätzlich stimme ich zu, daß es „unter normalen Umständen“ keinen großen Unterschied macht, welche Shell nun verwendet wird. Das Problem ist aber, daß diese „normalen Umstände“ nicht das sind, womit der Admin rechnen darf.
Gegen die
tcsh
spricht allerdings, dass sie als csh-Abkömmling grundsätzlich nicht POSIX-kompatibel ist.Warum daran festgehalten wird, erschließt sich mir nicht. Mir scheint, FreeBSD macht es damit unnötig kompliziert. Bei OpenBSD ist einfach für alles ksh gesetzt, soweit ich mich erinnere. Damit kommt man, meiner Erfahrung nach, auch gut zurecht, wenn man bisher kaum was anderes als Bash benutzt hat.
Bei FreeBSD wird eben viel Wert auf Stabilität, Vertrautheit und POLA (policy of least astonishment) gesetzt. Veränderungen müssen gut begründet, durchdacht, getestet und ausgereift sein, bevor sie in FreeBSD landen. Ist ein wenig wie bei Slackware, dass mittlerweile dabei ist PAM in Slackware-current und somit auch in die vermutlich nicht mehr all zu fern liegende Veröffentlichung der Version 15 zu integrieren.
Das hat große Vorteile, aber eben auch Nachteile. Letztlich ist es subjektiv, wie man diese für sich auslegt bzw. die Prioritäten setzt.
Eine alternative Shell ist nur wenige Befehle auf der tcsh entfernt.
Ich denke, das dieses Phänomen einfach auf die Tatsache der Verbreitung und der Bekanntheit zurückzuführen ist. Selbst Apple ist von der tcsh als Teil der Überschneidungen mit FreeBSD dann doch auf die Bash gewechselt, solange diese noch unter GPL2 lizensiert gewesen. Die alte GPL2-Version der Bash wurde noch eine Weile mitgeschleppt bis aus lizenztechnischen Gründen irgendwann die zsh Einzug hielt.
Zu der Sache in Ihrem dritten Absatz kann ich leider nichts beitragen. Ich würde meinen, dass die Bash schon um einiges fetter ist als eine tcsh. Könnte es eventuell daran liegen, dass die tcsh aus irgendwelchen Gründen im Gegensatz zur Bash noch im Cache lag (System-Skripte / Cronjobs etc.)? Ansonsten habe ich dieses Verhalten unter großer Last schon ab und zu unter Linux erleben müssen. Im Jahr 2020 eigentlich technisch unnötig soetwas. Das geht auch gescheiter, wenn man die richtigen Designentscheidungen und Standardeinstellung durchsetzen würde.
Wie gesagt, ich denke, dass es auf den heutigen Kisten (Server und Desktops/Laptops) von der Stange aus Sicht der Hardwareressourcen keinen nennenswerten Unterschied mehr macht. Da sind andere Ressourcen wie bestehnde Kenntnis, verbreites Wissen, gute Doku und die Verbreitung einfach ausschlaggebender. Hinzu kommt aus Sicht der OSS-Projekte und -Communities, dass netto weniger Code gewartet werden muss, wenn man neben der Bash keine weitere Shell zu pflegen hat.
Weil /bin/ah nun mal eine posix compatible shell impliziert und wenn du mit dem shebang bashisms benutzt einfach ein Depp bist
Den shebang gibt es nicht aus Spass, viele Deppen kopieren sich das /bin/sh leider ohne Verstand wo zusammen und schreiben dann bash scripts drunter
Und warum gehen die davon aus, dass ich Bash-Skripte habe? Die Empfehlung klingt eher so, als wäre Dash nicht POSIX konform.
P.S.: Deinen Tonfall kannst du dir sonstwo hin stecken.
Weil du sonst keinen Grund für den Kommentar hättest? Mach dich mal schlau wo dash den Ursprung hat Herrgottnochmal
Bemitleidenswert... Geh mal ein Bier trinken, damit du runter kommst
It might be helpful to run chsh after logging in to change the default login shell, as dash is very limited.
Ist nicht die Begründung direkt in deinem Zitat?
LG