Legjobb válasz
Ezek mind kagylók, és még sok más van, amit nem említettél. Azt, hogy melyiket választja, személyes preferencia kérdése.
Az első héj a Bourne Shell (vagy sh) volt, és az alapértelmezett Unix hosszú ideig. Aztán jött egy fontos levezetés a Unixban, és a semmiből létrehoztak egy új héjat, a C Shell (vagy csh) nevet. Az öregedő Bourne-héjat ezután a kompatibilis, de sokkal erősebb Korn héj (vagy ksh) követte. A rendelkezésre álló héjak általában a következő kategóriák egyikébe tartoznak: Bourne / Korn Shell származék (bash), C Shell származék vagy klón (tcsh) vagy “egyéb” (például zsh).
Sok kagyló van válasszon, és ne csak azok közül, amelyeket említett. A GNU bash a Bourne / Korn Shell táborba esik, és manapság a legkülönbözőbb Unix és Linux változatok alapértelmezett héja. Ha héjterminált használtál Unix vagy Linux rendszeren, akkor valószínűleg ez volt az. Ha igazán és igazán szeretnéd a Bourne Shell-et (sh), úgy gondolom, hogy most már ingyenesen elérhető – de általában attól tartanak, hogy nincs elég funkciója. A Korn Shell visszafelé kompatibilis, és klónok (mksh) és a nemrég megjelent eredeti (ksh) formájában is ingyenes.
A C Shell esetében van tcsh, az eredeti csh kibővített klónja Kevesebb csh klón van, mert a csh-t nem tekintették előrelépésnek, és nincs annyi felhasználója – azonban a Unix sok BSD-verziója (például a FreeBSD és mások) alapértelmezett shellként fogja használni a csh-t. / p>
Vannak olyan változatok, amelyek nem kompatibilisek az sh / ksh vagy a csh-val – de általában fülkék. A kedvenceim ezen a téren a Scheme Shell (scsh) és a Plan 9 shell rc lennének – de ezeket alapértelmezés szerint soha nem telepítik Unixra vagy Linuxra, és az előbbi meglehetősen nagy. A zsh is ebbe az “egyéb” kategóriába tartozik.
Javaslatom háromszoros: először próbáld ki a rendszered alapértelmezett shelljét – szinte biztosan a GNU bash. A Bash mindenhol jelen van, és olvassa és végrehajtja a Bourne Shell és a Korn Shell programokat, összeférhetetlenség nélkül. Másodszor, próbálja ki az összes olyan héjat, amelyet valóban ki akar próbálni (például zsh vagy tcsh), és dolgozzon vele egy ideig, és nézze meg, hogy megfelel-e az Ön igényeinek. Végül csak azt használja, amelyik csak a kedvednek felel meg.
Ne feledje, hogy nem “ szkripteket kell írnia a használt héjba: Interaktívan használtam a C Shell-t, de nem voltam hajlandó programozni (az összes szkriptem a Korn Shell-et használta). Végül egy nap belemerültem a ksh-be, és soha nem néztem vissza.
Személyes kedvenceim ebben pont mksh (kiterjesztés nélküli Korn Shell klón) vagy GNU bash teljes Korn Shell kompatibilitással – vagy rc , az új Plan 9 operációs rendszer héja, amelynek állítólag Unix-utódnak kellett lennie (bár ez nem valósult meg).
Válasz
Mire jobb?
Milyen kritériumok vannak?
Személy szerint javaslom a bash -ot, mert ez az alapértelmezett Linux és MacOS X rendszereken, és könnyen elérhető minden más Unix formában és MS Windows alatt Cygwin keresztül, és ez az alapértelmezett a Microsoft ™ Windows Services for Linux ” (Ubuntu bash támogatási réteg / alrendszer).
Alapvetően ez a legkisebb ellenállás útja, ha sok különböző rendszert fog működtetni hosszú évek alatt … és gyakran csak frissen újraképezett rendszerekhez vagy frissen indított példányokhoz fog hozzáférni, minimális eltéréssel az operációs rendszer bázisától (mint skálázott webes / alkalmazáskiszolgáló farmoknál gyakori). Elég közel van a Korn-héjhoz, hogy kevesen találják meg azokat a sarokeseteket, ahol szemantikailag különböznek egymástól. (A legtöbb felhasználó nem veszi észre a különbséget a minimálisabb Bourne shell klónok, például a ash és a kötőjel és a bash hozzáadott tulajdonságok, még kevésbé képesek megkülönböztetni a ksh és bash .
iv zsh valószínűleg a legerősebb és testreszabható. Ez a legmegfelelőbb annak, aki igazán szenvedélyesen használja a héját és testreszabja azt. A használat hátránya… annak minden fejlesztésével és testreszabásával… az, hogy a felhasználó valószínűleg frusztrálónak találja, ha visszalép valamilyen más héj használatához, amikor hibakeresési problémák olyan rendszereken, ahol a (z) zsh még nincs telepítve – ezt az ops / sysadmins emberek a modern környezetekben meglehetősen gyakran teszik.Szintén meglehetősen kellemetlen, amikor kollégákkal dolgozunk vagy mentorálunk, és megpróbálunk nekik valamit megmutatni a shell parancssorukban, vagy megosztunk egy GNU képernyőt vagy tmux munkamenet velük.
A Korn shell, ksh , jobb shell a parancsfájlok készítéséhez, mint a bash néhány apró részletben … de nem annyira, hogy érdemes legyen mindenhova beolvasni, telepíteni és konfigurálni.
ksh sok éven át támogatta az “asszociatív tömböket” (hash / szótárak), mielőtt a bash hozzáadta. (Csak néhány évvel ezelőtt került hozzá a bash fájlhoz, még mindig nem szerepel azokban a verziókban, amelyek alapértelmezés szerint a MacOS X-szel szállítanak). Ezért általában az a legjobb, ha egyszerűen nem használsz asszociatív tömböket a shell parancsfájlokban. Ha úgy gondolja, hogy szeretné a funkcióit, akkor általában a legjobb, ha a Python, a Ruby, a Perl, a TCL / kívánságra vagy bármely más általános célú szkriptnyelvre vált. . Csak annyit nem lehet elérni, ha áttérünk egy másik héjra (a működési költségeket tekintve), csak azért, hogy csak egy funkciót lehessen elérni.
Ugyanez mondható el a ksh Közös folyamatok .
Az egyetlen figyelemre méltó különbség az, amelyet meg kell magyarázni. Vegye figyelembe a következő shell parancsot:
unset foo; echo bar | read foo; echo "$foo"
Ez tökéletesen érvényes minden Bourne-kompatibilis shellben. De másképp fog viselkedni különféle héjak alatt. Vagy kiadja a „bar” sztringet (és egy új sort), vagy csak az üres sort bocsátja ki.
bash megteszi ez utóbbi, míg a ksh és a zsh az előbbi módon fog teljesíteni. A „foo” shell változó az aktuális shellben lesz beállítva. Véleményem szerint ez az előnyben részesített szemantika.
De ez sarok eset. Amennyire tudom, nem vonatkoznak rá a Posix specifikációi a Unix héjra; tehát az a tény, hogy a viselkedés megvalósítástól függ, nem hiba. Ez csak egy olyan dolog, amellyel a héj szakértőjének tisztában kell lennie, és vagy tesztelnie kell, vagy ki kell dolgoznia.
Ennek a viselkedésnek az az oka, hogy a shellben lévő „pipe” operátor folyamatok közötti kommunikáció gépezet. A héjnak létre kell hoznia egy alhéjat, vagyis egy olyan alfolyamatot, amely a szülő folyamat memóriájának saját példányát futtatja. Bármely adott megvalósítás elemezheti a parancsot, és futtathatja az alhéjban a csőszimbólum előtti részt (balra) (ahogy ezt ksh és zsh ) vagy a cső után (jobbra) (ahogy bash tette, nagyon A ksh (1983-as kiadás előtt?) régi verziói és a régebbi Bourne-héj és a legtöbb klónjai, például ash és kötőjel .
Egy mű A parancs parancscsoportosítással biztosítja, hogy a cső után az összes parancs “hatókörben” legyen a read beépített módon:
unset foo; echo bar | { read foo; echo "$foo"; }
(Ez a példa egyébként egy finom hibát tár fel, amely a bash az 1.4-et megelőzően, és amelyet később kijavítottak; az elemző a karakterek és tokenek kezelésére használt ve ry hasonlóan a () (zárójelbe). Tehát azt szokta tolerálni, hogy a pontosvesszőt elhagyja a visszhangom után a „$ foo” – ami technikailag eltérést jelentett a specifikációtól. A probléma az, hogy emberek milliói használták a bash -t és szkripteket írtak abból a feltételezésből kiindulva, hogy nem kellett befejezni a parancsukat záró zárójel előtt – egy pontosvessző vagy új vonal. Tehát a régi shell szkriptek egy része még egy évtizeddel később is jól mutatja ezt a hibát, és csak néhány ember ismeri a héjat elég jól ahhoz, hogy észrevegye és kijavítsa). A bash egyértelműen felülmúlja a ksh -et, de valószínűleg nem egészen a zsh mindenki számára, aki elkötelezi magát a mélyen trükkös fejlesztések és testreszabások megtanulása és használata mellett.
bash támogatja a programozható [Tab] befejezést és a GNU readline könyvtárakat a billentyűzárak, a parancssori szerkesztés és a parancstörténethez való hozzáférés rendkívül rugalmas vezérléséhez.A ksh rendelkezik a viszonylag korlátozott fc paranccsal (amely bash is támogatja) a „fix parancsodhoz” – vagyis elemeket válasszon ki az előzményekből, húzza fel őket a kívánt szövegszerkesztőbe, és kilépéskor automatikusan futtassa a szerkesztett ideiglenes fájl tartalmát. / p>
De a bash ezt támogatja, és a saját emacs vagy vi az előzményekhez való hozzáférés és szerkesztés, valamint a régi csh ! (bang) operátorok is.
bash támogatja a vi szerkesztést mód ( set -o vi ), amely, ha jól emlékszem, az alapértelmezett volt a ksh 93. De a bash alapértelmezés szerint a emacs mód ( set -o emacs ). Ezenkívül természetesen a bash bind parancsot is felhasználhatja a kulcsok a sokféle szerkesztési és előzménykezelési funkció bármelyikéhez, vagy makrókba, amelyek kibővülnek bármilyen szöveggé, amelyet parancssorba helyezhet.
Ezenkívül bash számos „varázslatos” környezeti változóval rendelkezik, amelyek szinte elképzelhetetlenül finomak és bonyolultak. Például beállíthatja a PROMPT\_COMMAND változót úgy, hogy minden alkalommal végrehajtja az egyéni horgot, amikor bash hamarosan bemutatja a gyorsaságát. Tehát ellenőrizheti, hogy van-e varázslat .dot\_file , és személyre szabhatja a futó héjat annak alapján, hogy melyik könyvtárba tartozik, vagy visszaállíthatja a parancssor és a terminál képernyő színét a napszak alapján, vagy kérdezzen meg egy weboldalt, és automatikusan hajt végre néhány parancsot… bármi más alapján.
(Ezt a horgot arra használtam, hogy automatikusan aktiválja a Python virtuális környezeteket, egyszerűen áttérve a munkakönyvtárukra például).
Ha figyelembe vesszük a tcsh (vagy az őse, csh ) akkor egy kis résen vagy. Az EDA (elektronikus tervezés automatizálása) területén gyakran látni csh szkripteket. De ez a történelem balesete, és az ezen a területen dolgozó emberek többsége nem használja a tcsh -t interaktív használatához.
A hal héj is egy rés. Még soha nem használtam annyira, hogy véleményt alkothassak róla, és bizony elég színes. De azt hiszem, nagyon kemény sora lesz a kapálásra, mielőtt valóban széles körű követést művel. Hacsak az Apple ™ nem kezdi meg a Mac ™ rendszereinek alapértelmezett burkolataként történő szállítását, valószínűleg belátható időn belül elmarad a réstől.
Tehát remélem, hogy megértettem. Tényleg nincs sok értelme megkérdezni, hogy „mi a legjobb…” (nagyjából minden olyan dologból, ahol ésszerű alternatívák vannak).
A Unix parancshéjak esetében a Bourne-kompatibilis héjak közötti különbségek olyan kicsi, hogy csak a szakértők tudják megkülönböztetni őket, és ezek kompromisszumokat kötnek, és végül meglehetősen szubjektív preferenciákká válnak. Van olyan kollégám, aki szenvedélyes a zsh beállításaiért, és mások, akiket csak gondoz. Valahol a kettő között vagyok, hogy a legkönnyebben elérhető választáshoz igazodjak.