Bästa svaret
Det här är alla skal, och det finns många fler du inte nämnde. Vilket du väljer att använda är en fråga om personlig preferens.
Det första skalet var Bourne Shell (eller sh) och det var standard på Unix under lång tid. Sedan kom en större härledning i Unix och ett nytt skal skapades från grunden som heter C-skal (eller csh). Det åldrande Bourne Shell följdes sedan av det kompatibla men mycket kraftfullare Korn Shell (eller ksh). De tillgängliga skalen faller vanligtvis i en av dessa kategorier: Bourne / Korn Shell-derivat (bash), C Shell-derivat eller klon (tcsh) eller ”annat” (såsom zsh).
Det finns många skal att välj bland, och inte bara de du nämnde. GNU bash faller in i Bourne / Korn Shell-lägret och är standardskalet på en mängd olika Unix- och Linux-varianter idag. Om du har använt en skalterminal på Unix eller Linux är det troligt att det var den här. Om du verkligen och verkligen vill ha Bourne Shell (sh) tror jag att det nu är tillgängligt gratis – men det undviks i allmänhet att det inte har tillräckligt med funktioner. Korn Shell är bakåtkompatibel och är också gratis i form av kloner (mksh) och det nyligen släppta originalet (ksh).
För C Shell finns tcsh, en utökad klon av original csh . Det finns färre csh-kloner eftersom csh inte har uppfattats som en väg framåt och inte har så många användare – men många BSD-versioner av Unix (som FreeBSD och andra) använder csh som standardskal.
Det finns varianter som varken är kompatibla med sh / ksh eller csh – men de tenderar att vara nischskal. Mina favoriter i detta utrymme skulle vara Scheme Shell (scsh) och Plan 9 shell rc – men dessa är aldrig installerade som standard på Unix eller Linux och den förra är ganska stor. zsh faller också in i den här ”andra” kategorin.
Min rekommendation är tre gånger: först försök standardskalet på ditt system – nästan säkert GNU bash. Bash finns överallt och kommer att läsa och köra Bourne Shell och Korn Shell-program utan inkompatibilitet. För det andra, prova vart och ett av skalen du verkligen vill prova (som zsh eller tcsh) och arbeta med det ett tag och se om det uppfyller dina behov. Slutligen, använd bara det som passar dig.
Observera att du inte måste skriva skript i skalet du använder: Jag använde C-skalet interaktivt men vägrade att programmera i det (alla mina skript använde Korn-skalet). Slutligen tog jag en dag steget in i ksh och har aldrig sett mig tillbaka.
Mina personliga favoriter på detta punkt är mksh (en Korn Shell-klon utan tillägg) – eller GNU bash med full Korn Shell-kompatibilitet – eller rc , skalet från det nya operativsystemet Plan 9 som skulle vara en Unix-efterträdare (även om detta inte har gått igenom).
Svar
Bättre för vad?
Vilka är dina kriterier?
Personligen föreslår jag bash eftersom det är standard på Linux- och MacOS X-system och lätt tillgänglig på alla andra former av Unix och under MS Windows via Cygwin och är standard för Microsoft ™ Windows Services för Linux ” (Ubuntu bash supportlager / delsystem).
I grund och botten är det vägen för minst motstånd om du ska använda många olika system under många år … och ofta kommer att få tillgång till nyligen ombildade system eller nya lanserade instanser med minimala avvikelser från OS-basen (som är vanligt för skalade webb- / appserverfarmar). Det är tillräckligt nära Korn-skalet att få människor kommer att hitta hörnfall där de skiljer sig åt i semantik. (De flesta användare märker inte skillnaden mellan mer minimala Bourne-skalkloner som ash och dash och de funktioner som bash lägger till, mycket mindre att kunna skilja mellan skillnaderna mellan ksh och bash .
zsh är förmodligen den mest kraftfulla och anpassningsbar. Det passar bäst för någon som verkligen brinner för att använda och anpassa sitt skal. Nackdelen med att använda det … med alla dess förbättringar och anpassningar … är att användaren sannolikt kommer att finna det frustrerande att återvända till att använda något annat skal när felsökningsproblem på system där zsh inte (ännu) har installerats – vilket är något som ops / sysadmins folk i moderna miljöer gör ganska ofta.Det är också ganska obehagligt när man arbetar med eller mentorer kollegor och försöker visa dem något vid deras shell-prompt eller delar en GNU-skärm eller tmux -session med dem.
Korn-skalet, ksh , är ett bättre skal för skript än bash i några mindre detaljer … men inte tillräckligt för att vara värt att behöva hämta, installera och konfigurera det överallt.
ksh stödde ”associerande matriser” (hash / ordböcker) i många år innan bash lade till det. (Det lades bara till bash för några år sedan, är fortfarande inte inkluderat i de versioner som till exempel levereras med MacOS X). Så det är vanligtvis bäst att helt enkelt inte använda associerande matriser i dina skalskript. Om du tror att du vill ha dess funktioner är det oftast bäst att byta till Python, Ruby, Perl, TCL / önskan eller något av ett antal andra allmänna skriptspråk . Det finns bara inte så mycket att vinna genom att byta till ett annat skal (i termer av operativ overhead) bara för den ena funktionen.
Samma kan sägas om ksh Coprocesser .
Den enda andra anmärkningsvärda skillnaden är en som måste förklaras. Tänk på följande skalkommando:
unset foo; echo bar | read foo; echo "$foo"
Detta är perfekt giltigt i alla Bourne-kompatibla skal. Men det kommer att fungera annorlunda under olika skal. Det kommer antingen att avge strängen ”bar” (och en ny rad) eller så kommer den bara att avge den tomma raden.
bash kommer att göra den senare, medan ksh och zsh kommer att fungera på det tidigare sättet. Skalvariabeln ”foo” kommer att ställas in i det aktuella skalet. Enligt min mening är det den föredragna semantiken.
Men det här är ett hörnfall. Såvitt jag vet täcks det inte av Posix-specifikationerna för Unix-skalet; så det faktum att beteendet är implementeringsberoende är inte ett fel. Detta är bara något som en expert i skalet måste vara medveten om och antingen testa för eller kringgå.
Anledningen till detta beteende är att ”rör” -operatören i skalet är en kommunikation mellan process mekanism. Skalet måste skapa en subshell, det vill säga en delprocess som kör sin egen kopia av överordnadsprocessens minne. Vilken som helst implementering kan emellertid analysera kommandot och köra antingen delen före (till vänster om) rörsymbolen i subshell (som gjort av ksh och zsh ) eller efter (till höger om) röret (som gjort av bash, mycket gamla versioner av ksh (före 1983 års release?) och det äldre Bourne-skalet och de flesta av dess kloner som aska och streck .
Ett arbete runt är att använda kommandogruppering för att säkerställa att alla kommandon efter röret är ”in scope” med läst inbyggt så:
unset foo; echo bar | { read foo; echo "$foo"; }
(För övrigt exponerar detta exempel ett subtilt fel som fanns i bash före 1.4 och som fixades därefter; analysatorn används för att behandla {} tecken och tokens ry mycket som () (parenteser). Så det brukade tolereras att jag lämnade det semikolonet efter min echo “$ foo” – vilket tekniskt sett var en avvikelse från specifikationen. Problemet är att miljontals människor använde bash och skrev manus baserat på antagandet att de inte behövde avsluta sitt kommando före en stängning – med en semikolon eller en ny linje. Så några av dessa gamla skalskript visar fortfarande detta fel långt över ett decennium senare och det finns bara en handfull människor som känner till skalet tillräckligt bra för att upptäcka och fixa det.
När det gäller interaktiv användning, bash är klart överlägsen ksh men förmodligen inte helt i nivå med zsh för alla som förbinder sig att lära sig och använda djupt knepiga förbättringar och anpassningar.
bash stöder programmerbar [Tab] komplettering och GNU readline bibliotek för extremt flexibel kontroll över tangentbindningar, redigering av kommandoraden och tillgång till kommandot. ksh har det relativt begränsade fc kommandot (vilket bash stöder också) för ditt ”fix-kommando” – det vill säga för att välja objekt från din historik, dra upp dem i din önskade textredigerare och kör automatiskt innehållet i den redigerade tillfälliga filen vid avslutning.
Men bash stöder det och dess egna emacs eller vi historikåtkomst och redigering, och den gamla csh ! (bang) operatörer också.
bash support vi redigering läge ( set -o vi ) som, om jag minns rätt, var standard i ksh 93. Men bash är som standard emacs -läget ( set -o emacs ). Dessutom kan man naturligtvis också använda kommandot bash bind för att binda om alla nycklar till någon av ett stort antal redigerings- och historikmanipulationsfunktioner eller till makron som expanderar till vilken text du helst vill lägga på en kommandorad.
Dessutom bash har många ”magiska” miljövariabler som kan göra saker som är nästan otänkbart subtila och invecklade. Du kan till exempel ställa in PROMPT\_COMMAND för att köra en anpassad krok varje gång bash håller på att presentera sin uppmaning. Så du kan kontrollera den magiska .dot\_file och anpassa ditt löpande skal baserat på vilken katalog du befinner dig i, eller återställ din snabbsträng och terminalskärmsfärger baserat på tid på dagen, eller fråga någon webbplats och kör automatiskt något kommando baserat på … nästan vad som helst.
(Jag har använt den kroken för att automatiskt aktivera Python virtuella miljöer genom att helt enkelt byta till deras arbetskatalog till exempel).
När du överväger tcsh (eller dess förfader, csh ) så är du lite nischad. Det är vanligt att se csh -skript inom EDA (elektronisk designautomatisering). Men det är en historiaolycka och de flesta som arbetar inom detta område använder inte tcsh för sin interaktiva användning.
fisk skal är också en nisch. Jag har aldrig använt det tillräckligt för att bilda mig en uppfattning om det, och det är verkligen färgrikt nog. Men jag tror att det kommer att bli en mycket tuff rad att hacka innan den odlar en riktigt utbredd följd. Om inte Apple ™ börjar leverera det som standardskal för sina Mac ™ -system är det förmodligen dömt att stanna kvar i sin nisch under överskådlig framtid.
Så jag hoppas att jag har gjort poängen. Det är verkligen inte så mycket poäng att fråga ”vad som är bäst …” (i stort sett alla saker där det finns rimliga alternativ).
När det gäller Unix-kommandoskal är skillnaderna mellan de Bourne-kompatibla skalen så liten att endast experter kan skilja på dem, och de har avvägningar och så småningom kokar ner till ganska subjektiva preferenser. Jag har kollegor som brinner för deras zsh inställningar och andra som bara bryr sig. Jag är någonstans mellan att ha anpassat mig till det mest tillgängliga valet.