Si consiglia di utilizzare zsh invece di script bash? [chiuso]

Posso presumere che abbastanza persone abbiano zshinstallato per eseguire script con a

#!/usr/bin/env zsh

come shebang?

O questo renderà i miei script non eseguibili su troppi sistemi?

Chiarimento: sono interessato a programmi / script che un utente finale potrebbe voler eseguire (come su Ubuntu, Debian, SUSE, Arch ecc.)

Per portabilità, no. Sebbene zshpossa essere compilato su qualsiasi Unix o Unix-like e anche su Windows almeno tramite Cygwin, ed è confezionato per la maggior parte dei like Unix Open Source e diversi commerciali, in genere non è incluso nell'installazione predefinita.

bashdall'altro lato è installato su sistemi GNU (come bashla shell del progetto GNU) come la maggior parte dei sistemi basati su Linux non incorporati e talvolta su sistemi non GNU come Apple OS / X. Nel lato commerciale di Unix, la shell Korn (la variante AT&T, sebbene più ksh88quella) è la norma ed entrambi bashe zshsono in pacchetti opzionali. Sulle BSD, la shell interattiva preferito è spesso tcshmentre shè basata o guscio Almquist o pdkshe basho zshnecessità di essere installato come pacchetti opzionali pure.

zshè installato per impostazione predefinita su Apple OS / X. Era persino /bin/shlì. Può essere trovato di default in alcune distribuzioni Linux come SysRescCD, Grml, Gobolinux e probabilmente altre, ma non penso a nessuna delle principali.

Come per bash, c'è la domanda sulla versione installata e di conseguenza le funzionalità disponibili. Ad esempio, non è raro trovare sistemi con bash3o zsh3. Inoltre, non vi è alcuna garanzia che lo script per cui scrivete ora zsh5funzionerà zsh6anche se, come per il bashfatto che provano a mantenere la compatibilità con le versioni precedenti.

Per gli script, la mia opinione è: usare la sintassi della shell POSIX poiché tutti gli Unices hanno almeno una shell chiamata sh(non necessariamente in /bin) che è in grado di interpretare quella sintassi. Quindi non devi preoccuparti così tanto della portabilità. E se quella sintassi non è abbastanza per le tue necessità, allora probabilmente hai bisogno di più di una shell.

Quindi, le opzioni sono:

• Perl che è onnipresente (anche se potrebbe essere necessario limitarsi al set di funzionalità delle vecchie versioni e non è possibile fare ipotesi sui moduli Perl installati per impostazione predefinita)
• Specifica l'interprete e la sua versione (python 2.6 o successive, zsh 4 o successive, bash 4.2 o successive ...), come dipendenza per il tuo script, costruendo un pacchetto per ogni sistema di destinazione che specifica la dipendenza o stipulandolo in un file README fornito insieme allo script o incorporato come commenti nella parte superiore dello script o aggiungendo alcune righe nella sintassi Bourne all'inizio dello script che verifica la disponibilità dell'interprete richiesto e viene salvato con un errore esplicito quando non lo è, come questo script necessita di zsh 4.0 o versioni successive .
• Spedisci l'interprete insieme al tuo script (fai attenzione alle implicazioni della licenza), il che significa che hai bisogno anche di un pacchetto per ogni sistema operativo di destinazione. Alcuni interpreti rendono più semplice fornendo un modo per impacchettare lo script e il suo interprete in un unico eseguibile.
• Scrivilo in una lingua compilata. Ancora una volta, un pacchetto per sistema mirato.

No, non puoi. Ciò che è garantito disponibile è /bin/sh, essenzialmente la shell Bourne originale. Quasi tutte (notate il "quasi"!) Installazioni Linux avranno bash, ma sui sistemi * BSD è raro (la persecuzione BSD ha gravi dubbi sul codice GPL, come bash). Non so quale sia la shell standard su Mac, ma, di nuovo, ci sono dubbi su GPL. Lo stesso per Solaris.

zsh è una shell di nicchia, non è presente nell'installazione predefinita di Fedora (e non credo che sia quella predefinita per i maggiori distributori).

Penso che dipenda davvero da quali funzionalità extra di zsh stai usando e dove. Se hai intenzione di distribuire il tuo script tra i diversi utenti e sistemi, suggerirei di usare bash o anche sh .

Allo stesso tempo, se lo script è progettato per essere eseguito all'interno della tua organizzazione e hai la convenzione di avere zsh sui tuoi computer (ad esempio la stessa AMI di base) e le tue attività hanno chiari vantaggi da estensioni come selettori di file avanzati o altre cose da http: / /www.rayninfo.co.uk/tips/zshtips.html Direi che vai avanti!

Come dichiarato, bash è comunemente disponibile nell'installazione predefinita per molte distro. Il tuo script non raggiungerà la più grande base di utenti facendo affidamento su zsh.

Una domanda importante a cui rispondere prima di progettare la tua sceneggiatura è " Perché è importante in quale shell viene eseguita una sceneggiatura? "

Diverse shell utilizzano sintassi diverse o offrono funzioni di shell aggiuntive che potrebbero non essere supportate da altre shell. Per scrivere uno script per il "mondo generale degli utenti finali linux", determinare se lo script utilizza qualsiasi sintassi o funzioni shell che si basano su un particolare ambiente shell.

Ad esempio, la bashshell supporta determinate espansioni che non sono supportate da dashBourne shell o da qualsiasi altro /bin/shpunto sul sistema dell'utente.

$ ls -l /bin/sh 
lrwxrwxrwx 1 root root 4 Feb 19  2014 /bin/sh -> dash

Prova a eseguire echo {1..10}con/bin/sh rispetto a /bin/bashe otterrai un output molto diverso.

Lo stesso vale per il zshquale, pur supportando la maggior parte della bashsintassi, offre ulteriore espansione e sintassi che non è supportata dalla bashshell. Guarda questo tabelle confrontando le shell per esempi specifici.

Potresti ampliare la tua potenziale base di utenti oltre bashaderendo agli script che funzionano quando vengono chiamati #!/bin/sh -u. Tuttavia, ciò pone un'altra importante domanda da porsi: " Che cosa viene sacrificato in cambio di una maggiore portabilità? "

Determina se le differenze relative a problemi di sicurezza, funzionalità, efficienza o qualsiasi altra cosa che ritieni sia una priorità per la tua sceneggiatura varrebbero il sacrificio. Potrebbe non essere necessario un uso diffuso di uno script con una vulnerabilità di sicurezza nota solo perché funziona in più ambienti.

Così molti script sono scritti per bashquel supporto per questi script viene utilizzato come criterio quando si confrontano le shell dei comandi . Molte più persone saranno in grado di eseguire il tuo script che se si basa su zshqualsiasi altra sintassi esclusiva di un ambiente shell.

Inoltre, tieni presente che alla fine non hai il controllo su come l'utente esegue lo script (utile anche per il debug degli script in diverse shell ):

Ricorda che se usi una shell per leggere uno script di shell ("sh scriptname"), invece di eseguirlo direttamente ("./scriptname"), la shell tratterà tutti i commenti all'inizio dello script di shell come commenti. In particolare, il commento che specifica l'interprete da utilizzare durante l'esecuzione dello script (“#! / Bin / sh -u”) verrà ignorato, così come tutte le opzioni elencate accanto a quell'interprete.

Quindi, il meglio che puoi fare al riguardo è rendere portatili i tuoi script, fintanto che non ci sono grandi sacrifici su come funziona.

Potresti anche vedere le convenzioni di codifica Bash - StackTranslate.it .

L'unica cosa che puoi quasi garantire è che c'è un /bin/sh. Potrebbe essere una shell collegata staticamente, oppure può essere un collegamento a un'altra shell. Quell'altra shell di solito rileva che si chiama come sh e verrà eseguita in modalità compatibilità.

Notare il quasi nella prima frase.

Ogni sistema simile a unix su cui abbia mai lavorato lo aveva. Molti di loro avevano anche installato bash (ma non tutti . Ad esempio bash non è installato di default su alcuni BSD. Alcuni distributori Linux vengono forniti con DASH , la shell Debian Almquist.

Quello che puoi garantire sono le tue istruzioni di installazione. È possibile aggiungere una riga al file README indicando che è necessario zsh. Se si crea un pacchetto, è possibile contrassegnare zsh come dipendenza. Puoi verificarlo con gli strumenti autoconf / automake. Puoi verificare se zsh è stato trovato con nello script di installazione (inizia con / bin / sh e prova a localizzare zsh, se trovato continua. Se non viene visualizzato un errore, ad es. "Avvertenza: ZSH non è installato. Leggere il file delle istruzioni di installazione! ".)

Sono sicuro di aver dimenticato alcune altre opzioni. Ma i punti chiave sono:

• Non puoi garantire nulla fino a quando non lo avrai verificato.
• Sei quasi sicuro che / bin / sh sia presente e che puoi fare qualche controllo con quello.