Nejlepší odpověď
Toto jsou všechny skořápky a existuje ještě mnoho dalších, které jste nezmínil. Který z nich se rozhodnete použít, je věcí osobních preferencí.
První prostředí bylo Bourne Shell (nebo sh) a bylo výchozí nastavení pro Unix na dlouhou dobu. Pak přišla hlavní derivace v Unixu a od nuly byl vytvořen nový shell s názvem C Shell (nebo csh). Po stárnoucí Bourne Shell pak následovala kompatibilní, ale mnohem výkonnější Korn Shell (neboli ksh). Dostupné skořápky obecně spadají do jedné z těchto kategorií: derivace Bourne / Korn Shell (bash), C Shell derivát nebo klon (tcsh) nebo „jiné“ (například zsh).
Existuje mnoho skořápek vyberte si, nejen ty, které jste zmínili. GNU bash spadá do tábora Bourne / Korn Shell a dnes je výchozím shellem pro širokou škálu variant Unix a Linux. Pokud jste použili shell terminál na Unixu nebo Linuxu, je pravděpodobné, že to byl tento. Pokud opravdu a opravdu chcete Bourne Shell (sh), domnívám se, že je nyní k dispozici zdarma – ale obecně se vyhýbá tomu, že nemá dostatek funkcí. Korn Shell je zpětně kompatibilní a je také zdarma ve formě klonů (mksh) a nedávno vydaného originálu (ksh).
Pro C Shell existuje tcsh, rozšířený klon původního csh . Existuje méně klonů csh, protože csh nebyl považován za cestu vpřed a nemá tolik uživatelů – nicméně mnoho BSD verzí Unixu (například FreeBSD a další) použije jako výchozí shell csh.
Existují varianty, které nejsou kompatibilní ani s sh / ksh, ani csh – ale bývají to výklenkové skořápky. Moje oblíbené v tomto prostoru by byly Scheme Shell (scsh) a Plan 9 shell rc – ale ty se nikdy standardně neinstalují na Unix nebo Linux a ten první je dost velký. zsh také spadá do této „jiné“ kategorie.
Moje doporučení je trojí: nejprve vyzkoušejte ve svém systému výchozí prostředí – téměř jistě GNU bash. Bash je všude a bude číst a spouštět programy Bourne Shell a Korn Shell bez nekompatibility. Zadruhé vyzkoušejte všechny skořápky, které opravdu chcete vyzkoušet (například zsh nebo tcsh), a chvíli s nimi pracujte a zjistěte, zda splňují vaše potřeby. Nakonec použijte jen to, které z nich vyhovuje vašim potřebám.
Pamatujte, že nemusíte psát skripty do používaného prostředí: Použil jsem C Shell interaktivně, ale odmítl jsem v něm programovat (všechny moje skripty používaly Korn Shell). Nakonec jsem se jednoho dne ponořil do ksh a nikdy jsem se neohlédl.
Moje osobní oblíbené v tomto body jsou mksh (klon Korn Shell bez rozšíření) – nebo GNU bash s plnou kompatibilitou s Korn Shell – nebo rc , shell z nového operačního systému Plan 9, který měl být nástupcem Unixu (i když se to neuskutečnilo).
Odpověď
Lepší pro co?
Jaká jsou vaše kritéria?
Osobně navrhuji bash , protože je to výchozí v systémech Linux a MacOS X a snadno dostupné ve všech ostatních formách Unixu a pod MS Windows prostřednictvím Cygwin a je výchozí pro Microsoft ™ Windows Services pro Linux ” (Ubuntu bash podporuje vrstvu / subsystém).
V zásadě jde o cestu nejmenšího odporu, pokud budete po mnoho let provozovat mnoho různých systémů… a často budete mít přístup k čerstvě znovu zobrazeným systémům nebo novým spuštěným instancím s minimálními odchylkami od základny OS (jak je běžné pro škálované farmy webů / serverů aplikací). Kornovi je to dost blízké, že jen málo lidí najde rohové případy, kdy se liší sémantikou. (Většina uživatelů si nevšimne rozdílu mezi minimálnějšími klony prostředí Bourne, jako jsou ash a pomlčka a funkce, které bash dodává, natož aby bylo možné rozlišovat mezi rozdíly mezi ksh and bash .
zsh je pravděpodobně nejsilnější a přizpůsobitelné. Je to nejvhodnější pro někoho, kdo je opravdu vášnivý při používání a přizpůsobování svého prostředí. Nevýhodou jeho používání… se všemi jeho vylepšeními a přizpůsobeními… je, že pro uživatele bude pravděpodobně frustrující ustoupit k používání jiného prostředí, když problémy s laděním v systémech, kde zsh nebyl (dosud) nainstalován – což je něco, co lidé ops / sysadmins v moderních prostředích dělají poměrně často.Je to také docela nepříjemné, když pracujete s kolegy nebo s nimi provádíte mentorování a snažíte se jim něco ukázat na jejich příkazovém řádku nebo při sdílení obrazovky GNU nebo tmux relace s nimi.
Shell Korn, ksh , je lepší shell pro skriptování než bash v několika drobných detailech … ale ne natolik, aby to stálo za to načíst, nainstalovat a nakonfigurovat všude.
ksh podporoval „asociativní pole“ (hash / slovníky) po mnoho let, než jej bash přidal. (Byl přidán pouze do bash před několika lety, stále není například zahrnut ve verzích dodávaných s MacOS X ve výchozím nastavení). Obvykle je tedy nejlepší nepoužívat asociativní pole ve svých skriptech prostředí. Pokud si myslíte, že chcete jeho funkce, pak je obvykle nejlepší přejít na Python, Ruby, Perl, TCL / přání nebo na některý z mnoha dalších skriptovacích jazyků pro všeobecné účely . Prostě toho není tolik, co lze získat přechodem na jiný shell (pokud jde o provozní režii) jen pro tuto jednu funkci.
Totéž lze říci o ksh Koprocesy .
Jediným dalším významným rozdílem je rozdíl, který je třeba vysvětlit. Zvažte následující příkaz shellu:
unset foo; echo bar | read foo; echo "$foo"
To je naprosto platné v jakémkoli prostředí kompatibilním s Bourne. Ale pod různými granáty se bude chovat jinak. Bude vydávat řetězec „bar“ (a nový řádek), nebo bude vysílat pouze prázdný řádek.
bash bude dělat poslední, zatímco ksh a zsh budou fungovat stejným způsobem. Proměnná prostředí „foo“ bude nastavena v aktuálním prostředí. Podle mého názoru se jedná o upřednostňovanou sémantiku.
Je to ale rohový případ. Pokud vím, není to pokryto specifikacemi Posix pro unixový shell; skutečnost, že chování závisí na implementaci, není chyba. Toto je pouze něco, čeho si musí být odborník v shellu vědom, a buď jej otestovat, nebo vyřešit.
Důvodem tohoto chování je, že operátor „pipe“ v shellu je meziprocesní komunikace mechanismus. Shell musí vytvořit subshell, což je podproces, na kterém běží vlastní kopie paměti nadřazeného procesu. Jakákoli daná implementace však může analyzovat příkaz a spustit buď část před (nalevo) symbolem kanálu v subshellu (jak to dělá ksh a zsh ) nebo za (napravo od) potrubí (jak to dělá bash, velmi staré verze ksh (před vydáním roku 1983?) a starší prostředí Bourne a většina jeho klonů, jako je ash a pomlčka .
Jedna práce kolem je použít seskupení příkazů k zajištění toho, aby všechny příkazy po kanálu byly „v rozsahu“ s přečtením takto:
unset foo; echo bar | { read foo; echo "$foo"; }
(Mimochodem, tento příklad odhaluje jemnou chybu, která existovala v bash před 1.4 a který byl poté opraven; analyzátor používal ke zpracování {} znaků a tokenů ve podobně jako () (závorky). Dříve se tedy tolerovalo vynechání středníku po mém echo „$ foo“ – což byla technicky odchylka od specifikace. Problém je v tom, že miliony lidí používaly bash a psaly skripty na základě předpokladu, že nepotřebují ukončit svůj příkaz před zavírací závorkou – pomocí středník nebo nový řádek. Některé z těchto starých skriptů prostředí tedy tuto chybu stále vykazují i po deseti letech a existuje jen hrstka lidí, kteří znají prostředí dost dobře na to, aby jej našli a opravili.)
Pokud jde o interaktivní použití, bash je zjevně lepší než ksh , ale pravděpodobně není zcela srovnatelný s zsh pro každého, kdo by se zavázal učit se a používat hluboce složitá vylepšení a přizpůsobení.
bash podporuje programovatelné dokončení [Tab] a knihovny GNU readline pro extrémně flexibilní kontrolu nad klávesovými zkratkami, editaci příkazového řádku a přístup k historii příkazů. ksh má relativně omezený fc příkaz (který bash také podporuje) pro váš „opravný příkaz“ – to znamená vybrat položky z historie, vytáhnout je ve vašem preferovaném textovém editoru a při spuštění automaticky spustit obsah tohoto upraveného dočasného souboru.
Ale bash to podporuje i vlastní emacs nebo vi přístup a úpravy historie a starý csh ! (bang) operátoři také.
bash podpora vi úpravy režim ( set -o vi ), který byl, pokud si dobře pamatuji, výchozí v ksh 93. Ale bash je výchozí režim emacs ( set -o emacs ). Samozřejmě můžete také použít příkaz bash bind k opětovnému svázání libovolného klávesy libovolné z velkého počtu funkcí pro úpravy a manipulaci s historií nebo do maker rozšiřujících se o jakýkoli text, který byste chtěli vložit do příkazového řádku.
Navíc bash má mnoho „magických“ proměnných prostředí, které dokážou dělat věci, které jsou téměř nepředstavitelně jemné a složité. Můžete například nastavit proměnnou PROMPT\_COMMAND tak, aby prováděla vlastní zavěšení pokaždé, když je bash chystá předložit svou výzvu. Takže byste mohli nechat zkontrolovat nějaké kouzlo .dot\_file a znovu přizpůsobit běžící prostředí podle toho, ve kterém adresáři jste, nebo resetovat barvy řetězce řetězce a obrazovky terminálu na základě denní doby nebo dotazujte se na nějaký web a automaticky proveďte nějaký příkaz založený na … téměř na čemkoli.
(Použil jsem tento hák k automatické aktivaci virtuálních prostředí Pythonu jednoduše změnou na jejich pracovní adresář například).
Když vezmete v úvahu tcsh (nebo jeho předchůdce, csh ), pak jste trochu ve výklenku. Je běžné vidět skripty csh v oblasti EDA (automatizace elektronického návrhu). Ale to je náhoda historie a většina lidí pracujících v této oblasti nepoužívá tcsh pro své interaktivní použití.
The ryby shell je také výklenek. Nikdy jsem to nevyužil natolik, abych si na to vytvořil názor, a určitě je to dost barevné. Ale myslím si, že to bude muset mít velmi těžký řádek, který se bude pěstovat, než si vypěstuje skutečně rozšířené pokračování. Pokud jej Apple ™ nezačne dodávat jako výchozí prostředí pro své systémy Mac ™, je pravděpodobně odsouzeno zůstat v dohledné budoucnosti ve svém výklenku.
Takže doufám, že jsem to udělal. Opravdu nemá smysl ptát se „co je nejlepší…“ (skoro všeho, kde existují rozumné alternativy).
V případě skořápek příkazů Unix jsou rozdíly mezi skořápkami kompatibilními s Bourneem tak malé, že je mohou rozlišit jen odborníci, a ti mají kompromisy a nakonec se scvrkávají na spíše subjektivní preference. Mám kolegy, kteří jsou nadšení pro svá zsh nastavení a další, kterým záleží jen na tom. Jsem někde mezi tím, abych se přizpůsobil té nejsnadněji dostupné volbě.