Beste antwoord
Dit zijn allemaal shells, en er zijn er nog veel meer die je niet noemde. Welke je kiest, is een kwestie van persoonlijke voorkeur.
De eerste shell was de Bourne Shell (of sh) en dat was de standaard op Unix voor een lange tijd. Toen kwam er een belangrijke afleiding in Unix, en werd er een nieuwe shell gemaakt met de naam C Shell (of csh). De verouderende Bourne Shell werd vervolgens gevolgd door de compatibele maar veel krachtigere Korn Shell (of ksh). De beschikbare shells vallen over het algemeen in een van deze categorieën: Bourne / Korn Shell-derivaat (bash), C Shell-derivaat of kloon (tcsh) of “andere” (zoals zsh).
Er zijn veel shells om kies uit, en niet alleen degene die u noemde. GNU bash valt in het Bourne / Korn Shell-kamp en is tegenwoordig de standaardshell op een breed scala aan Unix- en Linux-varianten. Als je een shell-terminal op Unix of Linux hebt gebruikt, is de kans groot dat het deze was. Als je echt en echt Bourne Shell (sh) wilt, geloof ik dat het nu gratis beschikbaar is – maar het wordt over het algemeen gemeden omdat het niet genoeg functies heeft. De Korn Shell is achterwaarts compatibel, en is ook gratis in de vorm van klonen (mksh) en het recent uitgebrachte origineel (ksh).
Voor C Shell is er tcsh, een uitgebreide kloon van de originele csh Er zijn minder csh-klonen omdat de csh niet wordt gezien als een weg vooruit, en niet zoveel gebruikers heeft – maar veel BSD-versies van Unix (zoals FreeBSD en andere) zullen csh gebruiken als hun standaardshell. / p>
Er zijn varianten die niet compatibel zijn met sh / ksh of csh – maar het zijn meestal niche-shells. Mijn favorieten in deze ruimte zijn de Scheme Shell (scsh) en de Plan 9 shell rc – maar deze worden nooit standaard geïnstalleerd op Unix of Linux en de eerste is nogal groot. zsh valt ook in deze categorie “andere”.
Mijn aanbeveling is drieledig: probeer eerst de standaardshell op uw systeem – vrijwel zeker GNU bash. Bash is overal, en zal Bourne Shell- en Korn Shell-programmas lezen en uitvoeren zonder incompatibiliteit. Ten tweede, probeer elk van de shells die je echt wilt proberen (zoals zsh of tcsh), en werk er een tijdje mee om te zien of het aan je behoeften voldoet. Gebruik tenslotte gewoon wat u maar wilt.
Merk op dat u geen scripts hoeft te schrijven in de shell die u gebruikt: Ik gebruikte de C-shell interactief, maar weigerde erin te programmeren (al mijn scripts gebruikten de Korn-shell). Eindelijk, op een dag heb ik de sprong gewaagd in ksh en heb ik nooit meer achterom gekeken.
Mijn persoonlijke favorieten hier punten zijn mksh (een Korn Shell-kloon zonder extensies) – of GNU bash met volledige Korn Shell-compatibiliteit – of rc , de shell van het nieuwe Plan 9-besturingssysteem dat een Unix-opvolger had moeten zijn (hoewel dit niet is uitgekomen).
Antwoord
Beter voor wat?
Wat zijn uw criteria?
Persoonlijk stel ik voor bash omdat dit de standaard is op Linux- en MacOS X-systemen en direct beschikbaar op alle andere vormen van Unix en onder MS Windows via Cygwin en is de standaardinstelling voor de Microsoft ™ Windows Services voor Linux ” (Ubuntu bash ondersteuningslaag / subsysteem).
In feite is het de weg van de minste weerstand als je vele jaren lang veel verschillende systemen gaat gebruiken … en vaak toegang hebt tot systemen met een nieuwe image of nieuwe gelanceerde instanties met minimale afwijkingen van de OS-basis (zoals is gebruikelijk voor geschaalde web- / app-serverfarms). Het is dicht genoeg bij de Korn-schaal dat maar weinig mensen de hoekgevallen zullen vinden waarin ze verschillen in semantiek. (De meeste gebruikers zullen het verschil niet merken tussen meer minimale Bourne-shell-klonen zoals ash en streepje en de functies die bash toevoegt, laat staan om onderscheid te maken tussen de verschillen tussen ksh en bash .
zsh is waarschijnlijk de krachtigste en aanpasbaar. Het is het meest geschikt voor iemand die echt gepassioneerd is over het gebruiken en aanpassen van zijn shell. Het nadeel van het gebruik ervan … met al zijn verbeteringen en aanpassingen … is dat de gebruiker het waarschijnlijk frustrerend vindt om terug te gaan naar een andere shell wanneer foutopsporingsproblemen op systemen waarop zsh (nog) niet is geïnstalleerd – iets dat de ops / sysadmins-mensen in moderne omgevingen vrij vaak doen.Het is ook nogal onhandig als je met collegas werkt of ze begeleidt en ze iets probeert te laten zien bij hun shell-prompt of een GNU-scherm of tmux sessie met hen.
De Korn-shell, ksh , is een betere shell voor scripting dan bash in een paar kleine details … maar niet genoeg om het overal te moeten ophalen, installeren en configureren.
ksh ondersteunde “associatieve arrays” (hash / woordenboeken) vele jaren voordat bash het toevoegde. (Het is pas een paar jaar geleden toegevoegd aan bash , is nog steeds niet opgenomen in de versies die standaard met MacOS X worden geleverd, bijvoorbeeld). Het is dus meestal het beste om geen associatieve arrays te gebruiken in uw shell-scripts. Als u denkt dat u de functies ervan wilt, is het meestal het beste om over te schakelen naar Python, Ruby, Perl, TCL / wish of een van een aantal andere scripttalen voor algemeen gebruik . Er is gewoon niet zoveel te winnen door over te schakelen naar een andere shell (in termen van operationele overhead) alleen voor die ene feature.
Hetzelfde kan gezegd worden van ksh Coprocessen .
Het enige andere opmerkelijke verschil is er een die moet worden uitgelegd. Beschouw het volgende shell-commando:
unset foo; echo bar | read foo; echo "$foo"
Dit is perfect geldig in elke Bourne-compatibele shell. Maar het zal zich anders gedragen onder verschillende schalen. Het zal ofwel de tekenreeks “bar” (en een nieuwe regel) uitzenden, of alleen de lege regel.
bash is voldoende de laatste, terwijl ksh en zsh op de eerste manier zullen presteren. De shellvariabele “foo” wordt in de huidige shell ingesteld. Naar mijn mening is dat de semantiek die de voorkeur heeft.
Maar dit is een hoekgeval. Voor zover ik weet valt het niet onder de Posix-specificaties voor de Unix-shell; dus het feit dat het gedrag implementatie-afhankelijk is, is geen bug. Dit is slechts iets waarvan een expert in de shell op de hoogte moet zijn en ofwel testen of omzeilen.
De reden voor dit gedrag is dat de “pipe” -operator in de shell een communicatie tussen processen is mechanisme. De shell moet een subshell maken, dat wil zeggen een subproces dat zijn eigen kopie van het geheugen van het bovenliggende proces uitvoert. Elke implementatie kan de opdracht echter parseren en ofwel het gedeelte vóór (links van) het pijpsymbool in de subshell uitvoeren (zoals gedaan door ksh en zsh ) of na (rechts van) de pipe (zoals gedaan door bash, heel oude versies van ksh (vóór release 1983?) en de oudere Bourne-shell en de meeste van zijn klonen zoals ash en streepje .
Eén werk rond is om commandogroepering te gebruiken om ervoor te zorgen dat alle commandos na de pipe “binnen bereik” zijn met de read ingebouwd zoals:
unset foo; echo bar | { read foo; echo "$foo"; }
(Overigens legt dit voorbeeld een subtiele bug bloot die bestond in bash vóór 1.4 en die daarna werd opgelost; de parser die werd gebruikt om {} tekens en tokens te behandelen ve ry lijkt veel op de () (haakjes). Vroeger stond het dus toe om die puntkomma weg te laten na mijn echo “$ foo” – wat technisch gezien een afwijking was van de specificatie. Het probleem is dat miljoenen mensen bash gebruikten en scripts schreven op basis van de veronderstelling dat ze hun opdracht niet hoefden te beëindigen voordat een accolade werd gesloten – met een puntkomma of een nieuwe regel. Dus sommige van deze oude shell-scripts vertonen deze bug ruim een decennium later nog steeds en er zijn maar een handjevol mensen die de shell goed genoeg kennen om hem te herkennen en te repareren.
Wat betreft interactief gebruik, bash is duidelijk superieur aan ksh maar komt waarschijnlijk niet helemaal overeen met zsh voor iedereen die zich wil inzetten voor het leren en gebruiken van zeer lastige verbeteringen en aanpassingen.
bash ondersteunt programmeerbare [Tab] voltooiing en de GNU readline bibliotheken voor extreem flexibele controle over sneltoetsen, opdrachtregelbewerking en toegang tot iemands opdrachtgeschiedenis. ksh heeft de relatief beperkte fc -opdracht (die bash ondersteunt ook) voor uw “fix-opdracht” – dat wil zeggen om items uit uw geschiedenis te selecteren, ze op te halen in uw favoriete teksteditor en automatisch de inhoud van dat bewerkte tijdelijke bestand uit te voeren bij het afsluiten.
Maar bash ondersteunt dat en zijn eigen emacs of vi geschiedenis toegang en bewerking, en de oude csh ! (bang) operators.
bash ondersteuning vi bewerken mode ( set -o vi ) die, als ik me goed herinner, de standaard was in ksh 93. Maar bash is standaard ingesteld op de emacs -modus ( set -o emacs ). Daarnaast kan men natuurlijk ook het bash bind -commando gebruiken om opnieuw te binden toetsen voor een groot aantal bewerkings- en historiemanipulatiefuncties, of tot macros die worden uitgebreid tot elke tekst die u op een opdrachtregel wilt plaatsen.
Bovendien bash heeft veel “magische” omgevingsvariabelen die dingen kunnen doen die bijna onvoorstelbaar subtiel en ingewikkeld zijn. U kunt bijvoorbeeld de variabele PROMPT\_COMMAND instellen om elke keer dat bash is op het punt om zijn prompt te presenteren. Dus je zou die kunnen laten controleren op wat magisch .dot\_file en je actieve shell opnieuw kunnen aanpassen op basis van de directory waarin je je bevindt, of je promptstring en terminalschermkleuren resetten gebaseerd op het tijdstip van de dag, of zoek een website op en voer automatisch een commando uit op basis van … zo ongeveer alles.
(Ik heb die hook gebruikt om virtuele Python-omgevingen automatisch te activeren door simpelweg naar hun werkmap te gaan bijvoorbeeld).
Als je kijkt naar tcsh (of zijn voorouder, csh ) dan zit je in een niche. Het is gebruikelijk om csh -scripts te zien op het gebied van EDA (elektronische ontwerpautomatisering). Maar dat is een toevallige geschiedenis en de meeste mensen die in dat vakgebied werken, gebruiken tcsh niet voor hun interactieve gebruik.
De fish shell is ook een niche. Ik heb het nog nooit genoeg gebruikt om er een mening over te vormen, en het is zeker kleurrijk genoeg. Maar ik denk dat het een heel moeilijke ruzie zal hebben om te schoffelen voordat het een echt wijdverspreide aanhang ontwikkelt. Tenzij Apple ™ het begint te verzenden als de standaardshell voor hun Mac ™ -systemen, is het waarschijnlijk gedoemd om in de nabije toekomst in zijn niche te blijven.
Dus ik hoop dat ik het duidelijk heb gemaakt. Het heeft echt weinig zin om te vragen “wat is het beste …” (van vrijwel alles waar redelijke alternatieven zijn).
In het geval van Unix-opdrachtshells zijn de verschillen tussen de Bourne-compatibele shells zo klein dat alleen experts ze van elkaar kunnen onderscheiden, en die hebben compromissen en komen uiteindelijk neer op nogal subjectieve voorkeuren. Ik heb collegas die gepassioneerd zijn door hun zsh instellingen en anderen die er gewoon om geven. Ik zit ergens tussenin dat ik mezelf heb aangepast aan de meest gemakkelijk beschikbare keuze.