Bedste svar
Disse er alle skaller, og der er mange flere, du ikke nævnte. Hvilken du vælger at bruge, er et spørgsmål om personlig præference.
Den første skal var Bourne Shell (eller sh), og det var standard på Unix i lang tid. Derefter kom en større afledning i Unix, og en ny skal blev oprettet fra bunden kaldet C Shell (eller csh). Den aldrende Bourne Shell blev derefter efterfulgt af den kompatible, men meget mere kraftfulde Korn Shell (eller ksh). Skaller, der er tilgængelige, falder generelt i en af disse kategorier: Bourne / Korn Shell-derivat (bash), C Shell-derivat eller klon (tcsh) eller “andet” (såsom zsh).
Der er mange skaller at vælg fra, og ikke kun dem, du nævnte. GNU bash falder ind i Bourne / Korn Shell-lejren og er standardskallen på en lang række Unix- og Linux-varianter i dag. Hvis du har brugt en shell-terminal på Unix eller Linux, er chancerne for, at det var denne. Hvis du virkelig og virkelig vil have Bourne Shell (sh), tror jeg, det er nu tilgængeligt gratis – men det er generelt undgået at ikke have nok funktioner. Korn Shell er bagudkompatibel og er også gratis i form af kloner (mksh) og den nyligt frigivne original (ksh).
For C Shell er der tcsh, en udvidet klon af den originale csh . Der er færre csh-kloner, fordi csh ikke er set som en vej fremad, og ikke har så mange brugere – men mange BSD-versioner af Unix (såsom FreeBSD og andre) bruger csh som deres standard shell. / p>
Der er varianter, der hverken er kompatible med sh / ksh eller csh – men de har tendens til at være nicheskaller. Mine favoritter i dette rum ville være Scheme Shell (scsh) og Plan 9 shell rc – men disse er aldrig installeret som standard på Unix eller Linux, og den tidligere er ret stor. zsh falder også ind i denne “anden” kategori.
Min anbefaling er tredobbelt: prøv først standardskallen på dit system – næsten helt sikkert GNU bash. Bash er overalt og vil læse og udføre Bourne Shell og Korn Shell programmer uden inkompatibilitet. For det andet, prøv hver af de skaller, du virkelig vil prøve (såsom zsh eller tcsh), og arbejd med det et stykke tid, og se om det opfylder dine behov. Endelig skal du bare bruge den, der passer dig bedst.
Bemærk at du ikke skal skrive scripts i den skal, du bruger: Jeg brugte C Shell interaktivt, men nægtede at programmere i den (alle mine scripts brugte Korn Shell). Endelig tog jeg en dag springet ned i ksh og har aldrig set mig tilbage.
Mine personlige favoritter på dette punkt er mksh (en Korn Shell-klon uden udvidelser) – eller GNU bash med fuld Korn Shell-kompatibilitet – eller rc , shell fra det nye Plan 9-operativsystem, der skulle være en Unix-efterfølger (skønt dette ikke er realiseret).
Svar
Bedre til hvad?
Hvad er dine kriterier?
Personligt foreslår jeg bash fordi det er standard på Linux- og MacOS X-systemer og let tilgængelig på alle andre former for Unix og under MS Windows gennem Cygwin og er standard for Microsoft ™ Windows Services til Linux ” (Ubuntu bash supportlag / undersystem).
Dybest set er det den mindste modstands vej, hvis du vil betjene mange forskellige systemer på tværs af mange år … og ofte får adgang til nyt genafbildede systemer eller nye lancerede forekomster med minimale afvigelser fra OS-basen (som er almindeligt for skalerede web- / app-serverbedrifter). Det er tæt nok på Korn-skal, at kun få mennesker finder hjørnesagerne, hvor de adskiller sig i semantik. (De fleste brugere bemærker ikke forskellen mellem mere minimale Bourne-shell-kloner som aske og dash og de funktioner, som bash tilføjer, langt mindre være i stand til at skelne mellem forskellene mellem ksh og bash .
zsh er sandsynligvis den mest magtfulde og tilpasses. Det er bedst egnet til en person, der virkelig brænder for at bruge og tilpasse sin skal. Ulempen ved at bruge den … med alle dens forbedringer og tilpasninger … er, at brugeren sandsynligvis finder det frustrerende at vende tilbage til at bruge en anden skal, når fejlfindingsproblemer på systemer, hvor zsh ikke (endnu) er blevet installeret – hvilket er noget, som ops / sysadmins folk i moderne miljøer gør temmelig ofte.Det er også ret uhåndteret, når man arbejder med eller vejleder kolleger og prøver at vise dem noget ved deres shell-prompt eller deler en GNU-skærm eller tmux -session med dem.
Korn-skallen, ksh , er en bedre skal til scripting end bash i et par mindre detaljer … men ikke nok til at være værd at skulle hente, installere og konfigurere det overalt.
ksh understøttede “associative arrays” (hash / ordbøger) i mange år, før bash tilføjede det. (Det blev kun føjet til bash for et par år siden, er stadig ikke inkluderet i de versioner, der f.eks. Leveres med MacOS X som standard). Så det er normalt bedst at bare ikke bruge associerende arrays i dine shell-scripts. Hvis du tror, du vil have dens funktioner, er det normalt bedst at skifte til Python, Ruby, Perl, TCL / wish eller et hvilket som helst af en række andre generelle script-sprog . Der er bare ikke så meget at vinde ved at skifte til en anden skal (med hensyn til operationelle omkostninger) bare for den ene funktion.
Det samme kan siges om ksh Coprocesser .
Den eneste anden bemærkelsesværdige forskel er en, der skal forklares. Overvej følgende shell-kommando:
unset foo; echo bar | read foo; echo "$foo"
Dette er perfekt gyldigt i enhver Bourne-kompatibel shell. Men det vil opføre sig forskelligt under forskellige skaller. Enten udsender strengen “bar” (og en ny linje), eller den udsender kun den tomme linje.
bash vil gøre sidstnævnte, mens ksh og zsh fungerer på den tidligere måde. “Foo” shell-variablen indstilles i den aktuelle shell. Efter min mening er det den foretrukne semantik.
Men dette er en hjørnesag. Så vidt jeg ved, er det ikke dækket af Posix-specifikationerne for Unix-skalen; så det faktum, at adfærden er implementeringsafhængig, er ikke en fejl. Dette er blot noget, som en ekspert i skallen skal være opmærksom på og enten teste for eller arbejde rundt.
Årsagen til denne opførsel er, at “rør” -operatøren i skallen er en inter-proces kommunikation mekanisme. Skallen skal oprette en subshell, det vil sige en underproces, der kører sin egen kopi af forældreprocessens hukommelse. Enhver implementering kan imidlertid analysere kommandoen og køre enten delen før (til venstre for) rørsymbolet i subshell (som gjort af ksh og zsh ) eller efter (til højre for) røret (som gjort af bash, meget gamle versioner af ksh (før 1983-udgivelsen?) og den ældre Bourne-skal og de fleste af dets kloner såsom aske og dash .
Et arbejde rundt er at bruge kommandogruppering for at sikre, at alle kommandoer efter røret er “i omfang” med læst indbygget sådan:
unset foo; echo bar | { read foo; echo "$foo"; }
(I øvrigt udsætter dette eksempel en subtil fejl, der eksisterede i bash før 1.4, og som blev rettet derefter; parseren bruges til at behandle {} tegn og tokens ve ry ligesom () (parenteser). Så det plejede at tolerere at udelade det semikolon efter min ekko “$ foo” – hvilket teknisk set var en afvigelse fra specifikationen. Problemet er, at millioner af mennesker brugte bash og skrev manuskripter baseret på den antagelse, at de ikke behøvede at afslutte deres kommando inden en lukkende bøjle – med en semikolon eller en ny linje. Så nogle af disse gamle shell-scripts udviser stadig denne fejl godt over et årti senere, og der er kun en håndfuld mennesker, der kender skallen godt nok til at få øje på og rette den).
Hvad angår interaktiv brug, bash er klart bedre end ksh men sandsynligvis ikke helt på niveau med zsh til alle, der forpligter sig til at lære og bruge dybt vanskelige forbedringer og tilpasninger.
bash understøtter programmerbar [Tab] afslutning og GNU readline bibliotekerne til ekstremt fleksibel kontrol over tastebindinger, redigering af kommandolinje og adgang til ens kommandovejledning. ksh har den relativt begrænsede fc kommando (hvilken bash understøtter også) til din “fix-kommando” – det vil sige at vælge emner fra din historie, trække dem op i din foretrukne teksteditor og automatisk udføre indholdet af den redigerede midlertidige fil ved afslutning.
Men bash understøtter det og dets egne emacs eller vi historikadgang og redigering og den gamle csh ! (bang) operatører også.
bash support vi redigering mode ( set -o vi ), som, hvis jeg husker korrekt, var standard i ksh 93. Men bash er som standard emacs -tilstand ( sæt -o emacs ). Derudover kan man selvfølgelig også bruge kommandoen bash bind til at genbinde enhver nøgler til en hvilken som helst af et stort antal redigerings- og historikmanipulationsfunktioner eller til makroer, der udvides til enhver tekst, du muligvis vil lægge på en kommandolinje.
Derudover bash har mange “magiske” miljøvariabler, der kan gøre ting, der næsten ufatteligt er subtile og indviklede. For eksempel kan du indstille variablen PROMPT\_COMMAND til at udføre en brugerdefineret krog hver gang bash er ved at præsentere sin prompt. Så du kan få den til at kontrollere noget magisk .dot\_file og tilpasse din kørende shell igen ud fra hvilken mappe du er i, eller nulstil din promptstreng og terminalskærmfarver baseret på tidspunktet på dagen eller forespørgsel på et websted og automatisk udføre en kommando baseret på … næsten hvad som helst.
(Jeg har brugt den krog til automatisk at aktivere Python virtuelle miljøer ved blot at skifte til deres arbejdskatalog for eksempel).
Når du overvejer tcsh (eller dens forfader, csh ) så er du lidt i en niche. Det er almindeligt at se csh scripts inden for EDA (elektronisk designautomatisering). Men det er en historieulykke, og de fleste mennesker, der arbejder inden for dette felt, bruger ikke tcsh til deres interaktive brug.
fisk skal er også en niche. Jeg har aldrig brugt det nok til at danne mig en mening om det, og det er bestemt farverigt nok. Men jeg tror, det vil have en meget hård række at hakke, før den dyrker en virkelig udbredt følge. Medmindre Apple ™ begynder at sende det som standardskal til deres Mac ™ -systemer, er det sandsynligvis dømt til at forblive i sin niche i overskuelig fremtid.
Så jeg håber, jeg har gjort det. Der er virkelig ikke megen mening med at spørge “hvad er det bedste …” (stort set enhver ting, hvor der er rimelige alternativer).
I tilfælde af Unix-kommandoskaller er forskellene mellem de Bourne-kompatible skaller så lille, at kun eksperter kan skelne dem fra hinanden, og de har kompromiser og til sidst koges ned til temmelig subjektive præferencer. Jeg har kolleger, der er lidenskabelige for deres zsh indstillinger og andre, der bare plejer pleje. Jeg er et sted imellem at have tilpasset mig til det mest let tilgængelige valg.