Paras vastaus
Nämä ovat kaikki kuoret, ja monia muita et maininnut. Kumpi valitset käyttää, on henkilökohtaisten mieltymysten asia.
Ensimmäinen kuori oli Bourne-kuori (tai sh) ja se oli oletus Unixissa pitkään. Sitten tuli Unixin merkittävä johdannainen, ja uusi kuori luotiin tyhjästä nimeltä C Shell (tai csh). Vanhenevaa Bourne-kuorta seurasi sitten yhteensopiva, mutta paljon tehokkaampi Korn-kuori (tai ksh). Saatavilla olevat kuoret kuuluvat yleensä johonkin seuraavista luokista: Bourne / Korn-kuorijohdannainen (bash), C-kuorijohdannainen tai klooni (tcsh) tai ”muu” (kuten zsh).
Kuoria on useita valitse ei vain mainitsemiesi joukosta. GNU bash kuuluu Bourne / Korn Shell -leiriin ja on oletuskuori useille Unix- ja Linux-muunnelmille nykyään. Jos olet käyttänyt shell-terminaalia Unixissa tai Linuxissa, on todennäköistä, että se oli tämä. Jos todella ja todella haluat Bourne Shellin (sh), uskon, että se on nyt saatavana ilmaiseksi – mutta yleensä vältetään siltä, ettei sillä ole tarpeeksi ominaisuuksia. Korn Shell on taaksepäin yhteensopiva, ja se on myös ilmainen kloonien (mksh) ja äskettäin julkaistun alkuperäisen (ksh) muodossa.
C Shellissä on tcsh, alkuperäisen csh: n laajennettu klooni. Csh-klooneja on vähemmän, koska csh: tä ei ole pidetty eteenpäin, eikä sillä ole yhtä monta käyttäjää – kuitenkin monet Unixin BSD-versiot (kuten FreeBSD ja muut) käyttävät csh: tä oletuskuorenaan. / p>
On olemassa muunnelmia, jotka eivät ole yhteensopivia sh / ksh: n tai csh: n kanssa – mutta ne ovat yleensä markkinarakoja. Suosikkini tässä tilassa ovat Scheme Shell (scsh) ja Plan 9 shell rc – mutta näitä ei koskaan asenneta oletusarvoisesti Unixiin tai Linuxiin, ja edellinen on melko iso. zsh kuuluu myös tähän ”muuhun” luokkaan.
Suositteluni on kolminkertainen: kokeile ensin järjestelmän oletuskuorta – melkein varmasti GNU bash. Bash on kaikkialla, ja lukee ja suorittaa Bourne Shell- ja Korn Shell -ohjelmat ilman yhteensopimattomuutta. Toiseksi, kokeile kutakin kuorta, jonka todella haluat kokeilla (kuten zsh tai tcsh), ja työskentele sen kanssa jonkin aikaa ja katso, vastaako se tarpeitasi. Lopuksi, käytä vain sitä, mikä sopii mielikuvituksellesi.
Huomaa, että älä ” tarvitse kirjoittaa komentosarjoja käyttämääsi kuoreen: Käytin C-kuorta interaktiivisesti, mutta kieltäydyin ohjelmoimasta sitä (kaikki skriptejäni käyttivät Korn-kuorta). Lopuksi eräänä päivänä otin syksyn ksh: iin, enkä ole koskaan katsonut taaksepäin.
Omat suosikkini tässä kohta on mksh (Korn Shell -klooni ilman laajennuksia) – tai GNU bash, jossa Korn Shell on täysin yhteensopiva – tai rc , uuden Plan 9 -käyttöjärjestelmän kuori, jonka piti olla Unix-seuraaja (vaikka tämä ei ole toteutunut).
Vastaa
Mille parempi?
Mitkä ovat kriteerit?
Ehdotan henkilökohtaisesti bash , koska se on oletus Linux- ja MacOS X -järjestelmissä ja helposti saatavilla kaikissa muissa Unix-muodoissa ja MS Windows -käyttöjärjestelmässä Cygwinin kautta ja on Microsoft ™ Windows Services for Linux ” (Ubuntu bash -tukikerros / -alijärjestelmä).
Pohjimmiltaan se on vähiten vastarintaa, jos aiot käyttää monia erilaisia järjestelmiä monien vuosien ajan … ja pääsette usein käyttämään juuri uudelleen kuvattuja järjestelmiä tai uusia käynnistettyjä instansseja, joilla on minimaaliset poikkeamat käyttöjärjestelmästä (kuten on yleinen skaalatuille verkko- / sovelluspalvelintiloille). Se on riittävän lähellä Korn-kuorta, että harvat ihmiset löytävät kulmatapauksia, joissa ne eroavat toisistaan semantiikan suhteen. (Useimmat käyttäjät eivät huomaa eroa vähäisempien Bourne-kuorikloonien, kuten ash ja viiva ja ominaisuudet, jotka bash lisää, vielä vähemmän pystyttävä erottamaan ksh ja bash .
zsh on todennäköisesti tehokkain ja muokattavissa. Se sopii parhaiten henkilölle, joka on todella intohimoinen kuorensa käytöstä ja mukauttamisesta. Sen käytön haittapuoli … kaikilla parannuksillaan ja mukautuksillaan on, että käyttäjän on todennäköisesti turhauttavaa palata jonkin muun kuoren käyttöön, kun virheenkorjausongelmia järjestelmissä, joihin zsh ei ole (vielä) asennettu – mitä ops / sysadmins-ihmiset tekevät nykyaikaisissa ympäristöissä melko usein.Se on myös melko hankalaa työskennellessäsi kollegoiden kanssa tai mentoroitaessa niitä ja yrittää näyttää heille jotain heidän komentokehotteessaan tai jakaa GNU-näyttö tai tmux -istunto heidän kanssaan.
Korn-komentotulkki, ksh , on parempi komentosarjan komentotulkki kuin bash muutamissa pienissä yksityiskohdissa … mutta ei niin paljon, että kannattaa noutaa, asentaa ja konfiguroida se kaikkialta.
ksh tuki ”assosiatiivisia taulukoita” (hash / sanakirjoja) monta vuotta, ennen kuin bash lisäsi sen. (Se lisättiin vasta muutama vuosi sitten bash -palveluun, ei vieläkään sisälly esimerkiksi MacOS X: n mukana toimitettaviin versioihin.) Joten on yleensä parasta olla käyttämättä assosiatiivisia taulukoita shell-komentosarjoissasi. Jos luulet haluavasi sen ominaisuudet, on yleensä parasta vaihtaa Python, Ruby, Perl, TCL / toive tai mihin tahansa muuhun yleiskäyttöiseen komentosarjakieliin . Siirtyminen toiseen kuoreen (operatiivisten yleiskustannusten kannalta) vain sen yhden ominaisuuden vuoksi ei ole kovin paljoa saavutettavissa.
Sama voidaan sanoa ksh Yhteisprosessit .
Ainoa merkittävä ero on selitettävä. Harkitse seuraavaa komentokomentoa:
unset foo; echo bar | read foo; echo "$foo"
Tämä pätee täydellisesti missä tahansa Bourne-yhteensopivassa kuoressa. Mutta se käyttäytyy eri tavoin eri kuorien alla. Se joko lähettää merkkijonon ”bar” (ja uuden rivin) tai lähettää vain tyhjän rivin.
bash tekee jälkimmäinen, kun taas ksh ja zsh toimivat entisellä tavalla. ”Foo” -kuorimuuttuja asetetaan nykyiseen kuoreen. Mielestäni se on suositeltava semantiikka.
Mutta tämä on kulmatapaus. Sikäli kuin tiedän, se ei kuulu Unix-kuoren Posix-määritysten piiriin; joten se, että käyttäytyminen riippuu toteutuksesta, ei ole vika. Tämä on vain jotain, jonka kuoren asiantuntijan on oltava tietoinen ja joko testattava tai kiertävä.
Tämän syyn syynä on, että kuoren ”pipe” -operaattori on prosessien välinen viestintä mekanismi. Kuoren on luotava alikuori, eli aliprosessi, jolla on oma kopio vanhemman prosessin muistista. Jokainen toteutus voi kuitenkin jäsentää komennon ja suorittaa joko osan (ennen vasemmalla olevaa) putkisymbolin osaa alikuoressa (kuten ksh ja zsh ) tai putken jälkeen (oikealla) (kuten bash on tehnyt, hyvin vanhat versiot ksh -versiosta (ennen vuoden 1983 julkaisua?) ja vanhempi Bourne-kuori ja useimmat klooniensa, kuten ash ja viiva .
Yksi työ around on käyttää komentoryhmittelyä varmistaakseen, että kaikki putken jälkeen olevat komennot ovat ”soveltamisalassa” sisäänrakennetulla read -työkalulla:
unset foo; echo bar | { read foo; echo "$foo"; }
(Tämä esimerkki paljastaa hienovian virheen, joka oli olemassa bash ennen 1.4 ja joka korjattiin sen jälkeen; jäsennin käytti {} merkkien ja tunnusten käsittelyyn ve niin kuin () (suluissa). Joten se aikoi sietää, että jätät kyseisen puolipisteen pois kaiun ”$ foo” jälkeen – mikä oli teknisesti poikkeama spesifikaatiosta. Ongelmana on, että miljoonat ihmiset käyttivät bash -sovellusta ja kirjoittivat komentosarjoja olettaen, että heidän ei tarvinnut lopettaa komentoaan ennen sulkeutta – puolipiste tai uusi viiva. Joten näistä vanhoista komentosarjoista esittävät edelleen tätä virhettä yli vuosikymmenen ajan myöhemmin, ja vain harvat ihmiset tuntevat kuoren riittävän hyvin paikantaa ja korjata).
Interaktiivisessa käytössä bash on selvästi parempi kuin ksh , mutta luultavasti ei aivan samanlainen kuin zsh kaikille, jotka sitoutuvat oppimaan ja käyttämään erittäin hankalia parannuksia ja mukautuksia.
bash tukee ohjelmoitavaa [välilehti] -valmistelua ja GNU-readline -kirjastoja, jotka tarjoavat erittäin joustavan avaimen sidonnan hallinnan, komentorivin muokkauksen ja pääsyn komentohistoriaan. ksh : lla on suhteellisen rajoitettu komento fc (joka bash tukee myös) korjauskomentoa – eli valita kohteita historiastasi, vetää ne haluamaasi tekstieditoriin ja suorittaa muokatun väliaikaisen tiedoston sisältö poistuttaessa automaattisesti.
Mutta bash tukee sitä ja omia emacs tai vi historian käyttö ja muokkaus sekä vanha csh ! (bang) operaattorit.
bash tuki vi muokkaus mode ( set -o vi ), joka oli, jos muistan oikein, oletus ksh 93. Mutta bash on oletusarvoisesti emacs -tilassa ( set -o emacs ). Tietysti voidaan tietysti myös sitoa komentoja bash sidonta . avaimet mihin tahansa suureen määrään muokkaus- ja historian manipulointitoimintoja tai makroihin, jotka laajenevat tekstiksi, jonka haluat laittaa komentoriville.
Lisäksi bash : lla on monia ”maagisia” ympäristömuuttujia, jotka voivat tehdä asioita, jotka ovat lähes käsittämättömän hienovaraisia ja monimutkaisia. Voit esimerkiksi asettaa muuttujan PROMPT\_COMMAND suorittamaan mukautetun koukun aina, kun bash on aikeissa esittää sen nopea. Joten voisit pyytää tarkistamaan joitain taikuuksia .dot\_file ja mukauttamaan käynnissä olevaa kuorta uudelleen hakemistosi perusteella tai palauttamaan kehotteen merkkijono ja päätelaitteen värit tai kellonajan perusteella, tai kysele jotakin verkkosivustoa ja suorita komento automaattisesti mihin tahansa.
(Olen käyttänyt tätä koukkua aktivoidaksesi Python-virtuaaliympäristöt siirtymällä yksinkertaisesti heidän työhakemistoonsa esimerkiksi).
Kun otetaan huomioon tcsh (tai sen esi-isä, csh ), niin olet hieman kapealla. On yleistä nähdä csh -skriptejä EDA: n (sähköisen suunnitteluautomaation) alalla. Mutta se on historian onnettomuus, ja suurin osa tällä alalla työskentelevistä ihmisistä ei käytä tcsh : ta interaktiiviseen käyttöön.
kala -kuori on myös markkinarako. En ole koskaan käyttänyt sitä tarpeeksi muodostaakseni siitä mielipidettä, ja se on varmasti tarpeeksi värikäs. Mutta luulen, että sillä on erittäin kova rivi, ennen kuin se kasvattaa todella laajaa seuraajaa. Ellei Apple ™ aloita toimittaa sitä Mac ™ -järjestelmänsä oletuskuoreksi, se on todennäköisesti tuomittu pysymään kapeallaan lähitulevaisuudessa.
Joten toivon, että olen tehnyt asian. Ei todellakaan ole mitään syytä kysyä ”mikä on parasta …” (melkein mistä tahansa, jos on kohtuullisia vaihtoehtoja).
Unix-komentojen kuorien tapauksessa erot Bourne-yhteensopivien kuorien välillä ovat niin pieniä, että vain asiantuntijat voivat erottaa heidät toisistaan, ja heillä on kompromisseja ja ne loppuvat lopulta melko subjektiivisiin mieltymyksiin. Minulla on kollegoita, jotka ovat intohimoisia zsh -asetuksistaan, ja muita, jotka vain huolehtivat. Olen jossain välissä sopeutunut itselleni helpoimmin käytettävissä olevaan valintaan.