Die Frage, wieso die csh / tcsh unter FreeBSD voreingestellt ist, kommt alle paar Monate mal wieder auf den Mailinglisten hoch. Die einzige Antwort ist dann meist, dass es nur die Standardshell des Root-Accounts ist. User-Accounts haben keine Standard-Shell, adduser fragte nach und wenn man einfach auf Enter haut, gibt es die sh. Das Gleiche ist der Fall, wenn man mit pw keine Shell angibt. Weitere Antworten und Meinungen gibt es dazu meist nicht. Denn Shells sind genauso wie Editoren oder seit einiger Zeit auch init-Systeme eine hochemotionale Angelegenheit, bei der sich trotz langer Diskussionen mit hoher Tendenz zum Bikeshedding eh kein Konsens erreichen lässt. Also macht man das Fass erst gar nicht auf.
Die Traditionalisten wollen dann ihre csh / tcsh behalten. Ich habe sie selbst sehr lange Zeit genutzt und bin immer noch der Meinung, dass die tcsh eine sehr gute interaktive Shell ist. Die Möglichkeiten zur Manipulation der Historie, der mächtige Line-Editor und etwas obskurere Dinge wie Magic-Space bieten in dem Paket nur wenige andere Shells, die von mir benutzten Funktionen sogar nur die zsh komplett. Weshalb ich dann irgendwann auch irgendwann dahin gewechselt bin. Auch die Embedded Fraktion mag die tcsh, da sie eben eine gute interaktive Shell ist, dabei aber einen überschaubaren Speicherabdruck hat. zsh und bash sind da schon ganz andere Kaliber, sh und die verschiedenen Korn-Shells als interaktive Shell wieder unkomfortabler. Das Problem der csh / tcsh sind halt die rechte beschränkten Möglichkeiten für Redirects, File Descriptor Manipulation und die fürchterliche Scriptsprache. Gerade letztere war für mich irgendwann der Grund zum Wechsel, nicht erst 'sh' tippen zu müssen, wenn man eine Schleife ins Prompt hauen will, ist dann doch irgendwo schön. Und der vi-Mode der csh / tcsh ist unbenutzbar mies implementiert.
Die sagen wir mal mittlere Generation möchte eine Shell aus der weiteren Bourne-Familie. Das ist verständlich, die Bourne-Familie bietet eine gute Scriptsprache, viele Möglichkeiten für Redirects und File Descriptor Kram und oft noch mehr Goodies. Das Problem ist nur, welche der vielen Möglichkeiten. Die Einen wollen eine möglichst reine Bourne-Shell. Der Wunsch ist oft FreeBSDs sh um einige interaktive Funktionen zu erweitern. Nur führt das zwangsläufig zum Konflikt mit der Embedded Fraktion, die /bin/sh so schlank wie möglich halten möchte. Andere möchten eine Korn-Shell. ksh88 und ksh93 sind da die reinen Lehren, die mksh ist auch immer beliebt. In meinen Augen ist die mksh eine sehr schöne Shell, durch ihre sehr rudimentäre History-Implementierung aber problematisch. Die Bash-Fraktion ist ebenfalls stark, aber durch die GPL3 ist die Bash keine Option. Die zsh wiederum ist selbst in minimaler Fassung ohne die optionalen Module ein ziemliches Biest und mit ihrem recht schnellen Release-Zyklus nicht unbedingt mit dem konservativen Basissystem vereinbar.
Und dann gibt es die Jungsspunde, sowie Spezialisten. Dort sieht man die oben schon genannte fish immer öfter, ich hatte schon mehrere Schüler-Praktikanten, die sie voller Überzeugung nutzten. Seitdem das .Net-Framework auch unter Linux immer beliebter wird, wird es auch die Powershell. Es gab sogar schon ein GSoC-Projekt sie auf FreeBSD zu portieren. Python-Fans mögen ihre Xonsh. Und so weiter.
Kurz gesagt, man kann es nicht allen recht machen. Egal, was man als Standard-Shell für den Root-User wählt, es sind immer mehr Benutzer unzufrieden als glücklich. Und daher bleibt es eben csh / tcsh, weil sie es immer waren. Und mal ehrlich. Die 5 Minuten im Monat, die man als root unterwegs ist, kann man damit leben. Und wenn nicht, kann man immer noch den toor-User aktivieren, ihn auf csh / tcsh lassen und die Shell vom root umstellen. Zerschießt man sie sich durch ein schiefgegangenes Paketupdate oder so, rettet man sich mit toor.
