Beste svaret
Dette er alle skjell, og det er mange flere du ikke nevnte. Hvilken du velger å bruke er et spørsmål om personlig preferanse.
Det første skallet var Bourne Shell (eller sh), og det var standard på Unix i lang tid. Så kom en større avledning i Unix, og et nytt skall ble opprettet fra grunnen av kalt C Shell (eller csh). Det aldrende Bourne Shell ble deretter fulgt av det kompatible, men mye kraftigere Korn Shell (eller ksh). Skjellene som er tilgjengelige faller generelt inn i en av disse kategoriene: Bourne / Korn Shell-derivat (bash), C Shell-derivat eller klon (tcsh) eller «annet» (som zsh).
Det er mange skall å velge mellom, og ikke bare de du nevnte. GNU bash faller inn i Bourne / Korn Shell-leiren, og er standardskallet på et bredt utvalg av Unix- og Linux-varianter i dag. Hvis du har brukt en skallterminal på Unix eller Linux, er sjansen stor for at det var denne. Hvis du virkelig og virkelig vil ha Bourne Shell (sh), tror jeg at den nå er tilgjengelig gratis – men den blir generelt unngått som ikke å ha nok funksjoner. Korn Shell er bakoverkompatibel, og er også gratis i form av kloner (mksh) og den nylig utgitte originalen (ksh).
For C Shell er det tcsh, en utvidet klon av den opprinnelige csh . Det er færre csh-kloner fordi csh ikke har blitt sett på som en vei fremover, og ikke har så mange brukere – men mange BSD-versjoner av Unix (som FreeBSD og andre) vil imidlertid bruke csh som standard skall.
Det finnes varianter som verken er kompatible med sh / ksh eller csh – men de har en tendens til å være nisjeskall. Mine favoritter i dette rommet ville være Scheme Shell (scsh) og Plan 9 shell rc – men disse er aldri installert som standard på Unix eller Linux, og den tidligere er ganske stor. zsh faller også inn i denne «andre» kategorien.
Min anbefaling er tre ganger: prøv først standardskallet på systemet ditt – nesten helt sikkert GNU bash. Bash er overalt, og vil lese og utføre Bourne Shell og Korn Shell-programmer uten inkompatibilitet. For det andre, prøv hvert av skallene du virkelig vil prøve (for eksempel zsh eller tcsh), og arbeid med det en stund og se om det oppfyller dine behov. Til slutt er det bare å bruke den som passer deg.
Merk at du ikke må skrive skript i skallet du bruker: Jeg brukte C-skallet interaktivt, men nektet å programmere i det (alle manusene mine brukte Korn-skallet). Til slutt tok jeg en dag steget ned i ksh og har aldri sett meg tilbake.
Mine personlige favoritter på dette punkt er mksh (en Korn Shell-klon uten utvidelser) – eller GNU bash med full Korn Shell-kompatibilitet – eller rc , skallet fra det nye Plan 9-operativsystemet som skulle være en Unix-etterfølger (selv om dette ikke har blitt noe av).
Svar
Bedre for hva?
Hva er kriteriene dine?
Personlig foreslår jeg bash fordi det er standard på Linux- og MacOS X-systemer og lett tilgjengelig på alle andre former for Unix og under MS Windows gjennom Cygwin og er standard for Microsoft ™ Windows Services for Linux ” (Ubuntu bash støttelag / delsystem).
I utgangspunktet er det veien for minst motstand hvis du skal bruke mange forskjellige systemer over mange år … og ofte vil få tilgang til nybildede systemer eller nye lanserte forekomster med minimale avvik fra OS-basen (som er vanlig for skalerte nett- / app-serverfarm). Det er nær nok til Korn shell at få mennesker vil finne hjørnesakene der de er forskjellige i semantikk. (De fleste brukere vil ikke merke forskjellen mellom mer minimale Bourne-shell-kloner som ask og dash og funksjonene som bash legger til, langt mindre være i stand til å skille mellom forskjellene mellom ksh og bash .
zsh er sannsynligvis den kraftigste og tilpasses. Den passer best for noen som virkelig brenner for å bruke og tilpasse skallet. Ulempen med å bruke det … med alle forbedringer og tilpasninger … er at brukeren sannsynligvis vil synes det er frustrerende å gå tilbake til å bruke et annet skall når feilsøkingsproblemer på systemer der zsh ikke (ennå) er installert – noe som ops / sysadmins-folkene i moderne miljøer gjør ganske ofte.Det er også ganske uhåndterlig når du jobber med eller veileder kollegaer og prøver å vise dem noe på skjellprompten eller deler en GNU-skjerm eller tmux økt med dem.
Korn-skallet, ksh , er et bedre skall for skripting enn bash i noen få mindre detaljer … men ikke nok til å være verdt å måtte hente, installere og konfigurere det overalt.
ksh støttet “associative arrays” (hash / dictionaries) i mange år før bash la til. (Den ble bare lagt til bash for noen år siden, er fortsatt ikke inkludert i versjonene som for eksempel leveres med MacOS X). Så det er vanligvis best å bare ikke bruke assosiative matriser i skallskriptene dine. Hvis du tror du vil ha funksjonene, er det vanligvis best å bytte til Python, Ruby, Perl, TCL / ønske eller noen av en rekke andre generelle skriptspråk. . Det er bare ikke så mye å hente på å bytte til et annet skall (når det gjelder driftsomkostninger) bare for den ene funksjonen.
Det samme kan sies om ksh Coprocesses .
Den eneste andre bemerkelsesverdige forskjellen er en som må forklares. Vurder følgende skallkommando:
unset foo; echo bar | read foo; echo "$foo"
Dette er perfekt gyldig i alle Bourne-kompatible skall. Men det vil oppføre seg annerledes under forskjellige skall. Den sender enten strengen «bar» (og en ny linje) eller den sender bare den tomme linjen.
bash vil gjøre sistnevnte, mens ksh og zsh vil utføre på den tidligere måten. «Foo» skallvariabelen vil bli satt i det nåværende skallet. Etter min mening er det den foretrukne semantikken.
Men dette er en hjørnesak. Så vidt jeg vet er det ikke dekket av Posix-spesifikasjonene for Unix-skallet; så det at oppførselen er avhengig av implementering, er ikke en feil. Dette er bare noe som en ekspert i skallet må være klar over og enten teste for eller omgå.
Årsaken til denne oppførselen er at «rør» -operatøren i skallet er en kommunikasjon mellom prosesser mekanisme. Skallet må lage et subshell, det vil si en underprosess som kjører sin egen kopi av foreldreprosessens minne. Enhver implementering kan imidlertid analysere kommandoen og kjøre enten delen før (til venstre for) rørsymbolet i subshell (som gjort av ksh og zsh ) eller etter (til høyre for) røret (som gjort av bash, veldig gamle versjoner av ksh (før 1983-utgivelsen?) og det eldre Bourne-skallet og de fleste av klonene som aske og dash .
Ett arbeid rundt er å bruke kommandogruppering for å sikre at alle kommandoene etter røret er «i omfang» med lest innebygd slik:
unset foo; echo bar | { read foo; echo "$foo"; }
(Forøvrig eksponerer dette eksemplet en subtil feil som eksisterte i bash før 1.4 og som ble løst etterpå; parseren brukes til å behandle {} tegn og tokens ry mye som () (parenteser). Så det pleide å tolerere å utelate det semikolonet etter ekko “$ foo” – som teknisk sett var et avvik fra spesifikasjonen. Problemet er at millioner av mennesker brukte bash og skrev manus basert på antagelsen om at de ikke trengte å avslutte kommandoen før en avsluttende brace – med en semikolon eller en ny linje. Så noen av disse gamle skallskriptene viser fremdeles denne feilen godt over et tiår senere, og det er bare en håndfull mennesker som kjenner skallet godt nok til å oppdage og fikse det).
Når det gjelder interaktiv bruk, bash er klart bedre enn ksh men sannsynligvis ikke helt på nivå med zsh for alle som vil forplikte seg til å lære og bruke dypt vanskelige forbedringer og tilpasninger.
bash støtter programmerbar [Tab] fullføring og GNU readline biblioteker for ekstremt fleksibel kontroll over tastebindinger, redigering av kommandolinje og tilgang til kommandolinjen. ksh har den relativt begrensede fc kommandoen (som bash støtter også) for «fix-kommandoen» – det vil si å velge elementer fra historikken din, trekke dem opp i ønsket teksteditor og automatisk utføre innholdet i den redigerte midlertidige filen ved avslutning.
Men bash støtter det og dets egne emacs eller vi historikkadgang og redigering, og den gamle csh ! (bang) operatører også.
bash støtter vi redigering modus ( set -o vi ) som var, hvis jeg husker riktig, standard i ksh 93. Men bash er som standard emacs -modus ( sett -o emacs ). I tillegg kan man selvfølgelig også bruke bash bind kommandoen for å gjenbinde alle nøkler til et hvilket som helst av et stort antall redigerings- og historikkmanipuleringsfunksjoner, eller til makroer som utvides til hvilken som helst tekst du kanskje vil legge på en kommandolinje.
I tillegg bash har mange «magiske» miljøvariabler som kan gjøre ting som nesten utenkelig er subtile og intrikate. For eksempel kan du stille inn PROMPT\_COMMAND -variabelen for å utføre en tilpasset krok hver gang bash er i ferd med å presentere ledeteksten. Så du kan få den til å se etter noe magisk .dot\_file og tilpasse kjøreskallet ditt på nytt basert på hvilken katalog du er i, eller tilbakestille spørringsstrengen og terminalskjermfargene basert på tidspunktet på dagen, eller spørre på et nettsted og utfører automatisk noen kommandoer basert på … omtrent hva som helst.
(Jeg har brukt den kroken til å aktivere Python virtuelle miljøer automatisk ved å bare bytte til arbeidskatalogen deres for eksempel).
Når du vurderer tcsh (eller dens forfader, csh ) så er du litt i en nisje. Det er vanlig å se csh skript innen EDA (elektronisk designautomatisering). Men det er en historieulykke, og de fleste som arbeider innen dette feltet bruker ikke tcsh til interaktiv bruk.
The fisk skall er også en nisje. Jeg har aldri brukt det nok til å danne meg en mening om det, og det er absolutt fargerikt nok. Men jeg tror det kommer til å ha en veldig tøff rekke å hakke før den dyrker en virkelig utbredt følge. Med mindre Apple ™ begynner å sende det som standard skall for deres Mac ™ -systemer, er det sannsynligvis dømt til å forbli i sin nisje i overskuelig fremtid.
Så jeg håper jeg har gjort poenget. Det er egentlig ikke så mye poeng å spørre «hva er best …» (av stort sett alle ting der det er rimelige alternativer).
Når det gjelder Unix-kommandoskjell, er forskjellene mellom de Bourne-kompatible skallene så liten at bare eksperter kan skille dem fra hverandre, og de har kompromisser og til slutt koker ned til ganske subjektive preferanser. Jeg har kolleger som er lidenskapelige for deres zsh innstillinger og andre som bare bryr seg. Jeg er et sted i mellom å ha tilpasset meg til det mest tilgjengelige valget.