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.
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
tcshspricht 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.