Differenza tra sh e bash

Quando scriviamo programmi shell, usiamo spesso /bin/sh e /bin/bash . Di solito uso bash , ma non so quale sia la differenza tra loro.

Qual è la principale differenza tra bash e sh ?

Di cosa dobbiamo essere a conoscenza quando programmiamo in bash e sh ?

Cos’è sh

sh (o Shell Command Language) è un linguaggio di programmazione descritto dallo standard POSIX . Ha molte implementazioni ( ksh88 , dash , …). bash può anche essere considerato un’implementazione di sh (vedi sotto).

Poiché sh è una specifica, non un’implementazione, /bin/sh è un collegamento simbolico (o un collegamento reale) a un’implementazione effettiva sulla maggior parte dei sistemi POSIX.

Cos’è bash

bash iniziato come un’implementazione sh -compatibile (sebbene sia anteriore allo standard POSIX di alcuni anni), ma con il passare del tempo ha acquisito molte estensioni. Molte di queste estensioni possono modificare il comportamento degli script di shell POSIX validi, quindi bash non è una shell POSIX valida. Piuttosto, è un dialetto del linguaggio shell POSIX.

bash supporta uno switch --posix , che lo rende più conforms a POSIX. Cerca anche di imitare POSIX se invocato come sh .

sh = bash?

Per molto tempo, /bin/sh solito puntare a /bin/bash sulla maggior parte dei sistemi GNU / Linux. Di conseguenza, era quasi diventato sicuro ignorare la differenza tra i due. Ma questo ha iniziato a cambiare di recente.

Alcuni esempi popolari di sistemi in cui /bin/sh non punta a /bin/bash (e su alcuni dei quali /bin/bash potrebbe non esistere nemmeno) sono:

  1. Moderni sistemi Debian e Ubuntu, che symlink sh to dash di default;
  2. Busybox , che di solito viene eseguito durante l’avvio del sistema Linux come parte di initramfs . Usa l’implementazione della shell di ash .
  3. BSD e, in generale, qualsiasi sistema non Linux. OpenBSD usa pdksh , un discendente della shell Korn. FreeBSD’s sh è un discendente della shell Bourne UNIX originale. Solaris ha le sue caratteristiche che per lungo tempo non erano conformi a POSIX; un’implementazione gratuita è disponibile dal progetto Heirloom .

Come puoi scoprire cosa /bin/sh punta sul tuo sistema?

La complicazione è che /bin/sh potrebbe essere un link simbolico o un hard link. Se si tratta di un collegamento simbolico, un modo semplice per risolverlo è:

 % file -h /bin/sh /bin/sh: symbolic link to bash 

Se è un collegamento difficile, prova

 % find -L /bin -samefile /bin/sh /bin/sh /bin/bash 

In effetti, la flag -L copre sia i collegamenti simbolici che quelli hardlinks, ma lo svantaggio di questo metodo è che non è portabile – POSIX non richiede find per supportare l’opzione -samefile , sebbene sia GNU find che FreeBSD find lo supportano.

Linea Shebang

In definitiva, spetta a te decidere quale usare, scrivendo la riga «shebang».

Per esempio

 #!/bin/sh 

userà sh (e qualunque cosa accada a indicare),

 #!/bin/bash 

userà /bin/bash se è disponibile (e fallirà con un messaggio di errore se non lo è). Naturalmente, puoi anche specificare un’altra implementazione, ad es

 #!/bin/dash 

Quale usare

Per i miei script personali, preferisco sh per i seguenti motivi:

  • è standardizzato
  • è molto più semplice e facile da imparare
  • è portatile su tutti i sistemi POSIX – anche se capita di non avere bash , è necessario avere sh

Ci sono anche dei vantaggi nell’usare bash . Le sue caratteristiche rendono la programmazione più conveniente e simile alla programmazione in altri moderni linguaggi di programmazione. Questi includono cose come le variabili locali e gli array. Plain sh è un linguaggio di programmazione molto minimalista.

sh : http://man.cx/sh
bash : http://man.cx/bash

TL; DR : bash è un superset di sh con una syntax più elegante e più funzionalità. È quasi sicuro usare una linea di shebang bash in quasi tutti i casi poiché è abbastanza onnipresente sulle piattaforms moderne.

NB: in alcuni ambienti, sh è bash . Controllare la sh --version .

Pubblica da UNIX.COM

Caratteristiche della shell

Questa tabella di seguito elenca la maggior parte delle funzionalità che penso possano farti scegliere una shell rispetto a un’altra. Non è inteso per essere un elenco definitivo e non include ogni singola funzione ansible per ogni singola shell ansible. Una funzionalità è considerata in una shell solo se nella versione fornita con il sistema operativo o se è disponibile come compilata direttamente dalla distribuzione standard. In particolare, la shell C specificata di seguito è quella disponibile su SUNOS 4. *, un numero considerevole di fornitori ora distribuisce tcsh o la propria shell C avanzata (non sempre rendono ovvio che stiano distribuendo tcsh.

Codice:

  sh csh ksh bash tcsh zsh rc es Job control NYYYYYNN Aliases NYYYYYNN Shell functions Y(1) NYYNYYY "Sensible" Input/Output redirection YNYYNYYY Directory stack NYYYYYFF Command history NYYYYYLL Command line editing NNYYYYLL Vi Command line editing NNYYY(3) YLL Emacs Command line editing NNYYYYLL Rebindable Command line editing NNNYYYLL User name look up NYYYYYLL Login/Logout watching NNNNYYFF Filename completion NY(1) YYYYLL Username completion NY(2) YYYYLL Hostname completion NY(2) YYYYLL History completion NNNYYYLL Fully programmable Completion NNNNYYNN Mh Mailbox completion NNNN(4) N(6) N(6) NN Co Processes NNYNNYNN Builtin artithmetic evaluation NYYYYYNN Can follow symbolic links invisibly NNYYYYNN Periodic command execution NNNNYYNN Custom Prompt (easily) NNYYYYYY Sun Keyboard Hack NNNNNYNN Spelling Correction NNNNYYNN Process Substitution NNNY(2) NYYY Underlying Syntax sh csh sh sh csh sh rc rc Freely Available NNN(5) YYYYY Checks Mailbox NYYYYYFF Tty Sanity Checking NNNNYYNN Can cope with large argument lists YNYYYYYY Has non-interactive startup file NYY(7) Y(7) YYNN Has non-login startup file NYY(7) YYYNN Can avoid user startup files NYNYNYYY Can specify startup file NNYYNNNN Low level command redefinition NNNNNNNY Has anonymous functions NNNNNNYY List Variables NYYNYYYY Full signal trap handling YNYYNYYY File no clobber ability NYYYYYNF Local variables NNYYNYYY Lexically scoped variables NNNNNNNY Exceptions NNNNNNNY 

Chiave per la tabella sopra.

La caratteristica Y può essere eseguita usando questa shell.

N La funzione non è presente nella shell.

F La funzione può essere eseguita solo utilizzando il meccanismo delle funzioni della shell.

L La libreria readline deve essere collegata alla shell per abilitare questa caratteristica.

Note alla tabella sopra

 1. This feature was not in the original version, but has since become almost standard. 2. This feature is fairly new and so is often not found on many versions of the shell, it is gradually making its way into standard distribution. 3. The Vi emulation of this shell is thought by many to be incomplete. 4. This feature is not standard but unofficial patches exist to perform this. 5. A version called 'pdksh' is freely available, but does not have the full functionality of the AT&T version. 6. This can be done via the shells programmable completion mechanism. 7. Only by specifying a file via the ENV environment variable. 

Questa domanda è stata spesso nominata come canonica per le persone che cercano di usare sh e si sorprendono che non si comporta come bash . Ecco una breve carrellata di equivoci e insidie ​​comuni.

Prima di tutto, dovresti capire cosa aspettarti.

  • Se esegui il tuo script con sh scriptname , o scriptname con scriptname e hai #!/bin/sh nella riga shebang , dovresti aspettarti un comportamento POSIX sh .
  • Se esegui il tuo script con bash scriptname , o scriptname con scriptname e hai #!/bin/bash (o l’equivalente locale) nella riga shebang, dovresti aspettarti il ​​comportamento di Bash.

Avere uno shebang corretto ed eseguire lo script digitando solo il nome dello script (possibilmente con un percorso relativo o completo) è generalmente la soluzione preferita. Oltre a uno shebang corretto, ciò richiede che il file di script abbia il permesso di esecuzione ( chmod a+x scriptname ).

Quindi, in che modo differiscono?

Il manuale di riferimento Bash ha una sezione che tenta di enumerare le differenze ma includono alcune fonti comuni di confusione

  • [[ non è disponibile in sh (solo [ che è più goffo e limitato].
  • sh non ha matrici.
  • Alcune parole chiave di Bash come local , function e select non sono trasferibili a sh .
  • Bash ha molte estensioni di syntax in stile C come $'string\nwith\tC\aescapes' e il tre-argomenti for((i=0;i<=3;i++)) ciclo, += incremento assegnazione, ecc.
  • Bash supporta <<<'here strings' .
  • Bash ha *.{png,jpg} e {0..9} espansione brace.
  • ~ riferisce a $HOME solo in Bash (e più in generale ~username alla home directory del username ).
  • Bash ha una sostituzione di processo con <(cmd) e >(cmd) .
  • Bash supporta coprocesses con <> reindirizzamento.
  • Bash ha esteso in modo significativo le strutture per l'aritmetica della shell (sebbene non abbia ancora supporto in virgola mobile) e la manipolazione della sottostringa variabile con ${substring:1:2} , ${variable/pattern/replacement} , conversione del caso, ecc.
  • Molte, molte estensioni di Bash per abilitare o disabilitare il comportamento opzionale ed esporre lo stato interno della shell.
  • Molte, molte funzionalità utili per l'uso interattivo che tuttavia non influiscono sul comportamento dello script.

Ricorda, questa è una lista abbreviata. Fare riferimento al manuale di riferimento per lo scoop completo e http://mywiki.wooledge.org/Bashism per molti buoni espedienti; e / o prova http://shellcheck.net/ che avverte per molte funzionalità di Bash.

Un errore comune è avere una riga #!/bin/bash shebang, ma comunque usare sh scriptname per eseguire effettivamente lo script. Questo in pratica disabilita qualsiasi funzionalità di solo Bash, quindi ottieni errori di syntax, ad esempio per provare a utilizzare gli array.

Sfortunatamente, Bash non avviserà quando proverai ad usare questi costrutti quando viene invocato come sh . Non disabilita completamente tutte le funzionalità di solo Bash, quindi, eseguendo Bash invocandolo come sh non è un buon modo per verificare se lo script è correttamente portatile a ash / dash / POSIX sh .

Shell è un’interfaccia tra utente e sistema operativo per accedere ai servizi di un sistema operativo. Può essere o GUI o CLI (interfaccia a riga di comando).

sh (Bourne sh ell) è un interprete di riga di comando della shell, per sistemi operativi Unix / Unix. Fornisce alcuni comandi incorporati. Nel linguaggio di scripting denotiamo l’interprete come #!/bin/sh . Era uno più ampiamente supportato da altre shell come bash (libero / aperto), kash (non gratuito).

Bash ( B ourne a gain s hell) è una sostituzione di shell per la shell Bourne. Bash è superset di sh. Bash supporta sh. POSIX è un insieme di standard che definiscono il modo in cui i sistemi conformi a POSIX dovrebbero funzionare. Bash non è in realtà una shell conforms a POSIX. In un linguaggio di scripting denotiamo l’interprete come #!/bin/bash .

Analogia:

  • Shell è come un’interfaccia o specifiche o API.
  • sh è una class che implementa l’interfaccia Shell.
  • Bash è una sottoclass di sh.

TERMINALE

  • programma / i che aprono una finestra
  • xterm, rxvt, konsole, kvt, gnome-terminal, nxterm ed eterm.

CONCHIGLIA

  • È un programma che viene eseguito nel terminale
  • Shell è sia un interprete di comandi che un linguaggio di programmazione
  • Shell è semplicemente un macro processore che esegue i comandi.
  • Processore macro significa funzionalità in cui testo e simboli vengono espansi per creare espressioni più grandi.

SH vs. BASH

SH

  • (Conchiglia)
  • È una shell specifica
  • un interprete di comandi e un linguaggio di programmazione
  • Predecessore di BASH

BASH

  • (Bourne-Again SHell)
  • È una shell specifica
  • un interprete di comandi e un linguaggio di programmazione
  • Ha sh funzionalità e altro ancora
  • Successore di SH
  • BASH è il SHELL predefinito

MATERIALE DI RIFERIMENTO:

SHELL gnu.org:

Alla sua base, una shell è semplicemente un macro processore che esegue i comandi. Il termine processore macro indica funzionalità in cui testo e simboli vengono espansi per creare espressioni più grandi.

Una shell Unix è sia un interprete di comandi che un linguaggio di programmazione. Come interprete dei comandi, la shell fornisce l’interfaccia utente al ricco insieme di utilità GNU. Le funzionalità del linguaggio di programmazione consentono di combinare queste utilità. I file contenenti comandi possono essere creati e diventano essi stessi comandi. Questi nuovi comandi hanno lo stesso stato dei comandi di sistema in directory come / bin, consentendo agli utenti o ai gruppi di stabilire ambienti personalizzati per automatizzare le loro attività comuni.

I gusci possono essere usati in modo interattivo o non interattivo. In modalità intertriggers, accettano l’input digitato dalla tastiera. Quando si esegue in modo non interattivo, le shell eseguono i comandi letti da un file.

Una shell consente l’esecuzione dei comandi GNU, sia in modo sincrono che asincrono. La shell attende il completamento dei comandi sincroni prima di accettare più input; i comandi asincroni continuano ad essere eseguiti in parallelo con la shell mentre legge ed esegue comandi aggiuntivi. I costrutti di reindirizzamento consentono un controllo a grana fine dell’input e dell’output di tali comandi. Inoltre, la shell consente di controllare il contenuto degli ambienti dei comandi.

Le conchiglie forniscono anche una piccola serie di comandi incorporati (builtins) che implementano funzionalità impossibili o scomode da ottenere tramite utilità separate . Ad esempio, cd, break, continue ed exec non possono essere implementati al di fuori della shell perché manipolano direttamente la shell stessa. Le proprietà history, getopts, kill o pwd, tra le altre, potrebbero essere implementate in utility separate, ma sono più convenienti da usare come comandi incorporati. Tutti i builtin della shell sono descritti nelle sezioni successive.

Mentre eseguire i comandi è essenziale, la maggior parte della potenza (e della complessità) delle shell è dovuta ai loro linguaggi di programmazione incorporati. Come ogni linguaggio di alto livello, la shell fornisce variabili, costrutti di controllo del stream, citazioni e funzioni.

Le conchiglie offrono caratteristiche specifiche per l’uso interattivo piuttosto che per aumentare il linguaggio di programmazione. Queste funzionalità interattive includono controllo dei processi, modifica della riga di comando, cronologia dei comandi e alias. Ciascuna di queste funzionalità è descritta in questo manuale.

BASH gnu.org:

Bash è la shell, o interprete di linguaggio di comando, per il sistema operativo GNU. Il nome è l’acronimo di “Bourne-Again SHell”, un gioco di parole su Stephen Bourne, l’autore dell’antenato diretto dell’attuale shell Unix sh, apparso nella settima edizione della Bell Labs Research versione di Unix.

Bash è ampiamente compatibile con sh e incorpora caratteristiche utili dalla shell Korn di Korn e dalla shell Csh di csh. È destinato ad essere un’implementazione conforms della parte IEEE POSIX Shell e Tools della specifica IEEE POSIX (IEEE Standard 1003.1). Offre miglioramenti funzionali su sh sia per l’uso interattivo che per la programmazione.

Mentre il sistema operativo GNU fornisce altre shell, inclusa una versione di csh, Bash è la shell predefinita . Come altri software GNU, Bash è abbastanza portatile. Funziona attualmente su quasi tutte le versioni di Unix e alcuni altri sistemi operativi: esistono porte supportate indipendentemente per piattaforms MS-DOS, OS / 2 e Windows.

Altre risposte in genere hanno evidenziato la differenza tra Bash e uno standard di shell POSIX. Tuttavia, quando si scrivono script di shell portatili e si usa la syntax di Bash, un elenco di tipici bashismi e corrispondenti soluzioni POSIX pure è molto utile. Tale elenco è stato compilato quando Ubuntu è passato da Bash a Dash come shell di sistema predefinita e può essere trovato qui: https://wiki.ubuntu.com/DashAsBinSh

Inoltre, c’è un ottimo strumento chiamato checkbashisms che controlla i bashismi nel tuo script e diventa utile quando vuoi assicurarti che il tuo script sia portatile.

/bin/sh può o non può richiamare lo stesso programma di /bin/bash .

sh supporta almeno le funzionalità richieste da POSIX (presupponendo una corretta implementazione). Può supportare anche le estensioni.

bash , “Bourne Again Shell”, implementa le funzionalità richieste per le estensioni sh più specifiche per bash. Il set completo di estensioni è troppo lungo per essere descritto qui e varia a seconda delle nuove versioni. Le differenze sono documentate nel manuale di bash. Digitare info bash e leggere la sezione “Funzionalità Bash” (sezione 6 nella versione corrente) oppure leggere la documentazione corrente online .

Bash (bash) è una delle molte shell Unix disponibili (eppure le più usate). Bash sta per “Bourne Again SHell” ed è un sostituto / miglioramento dell’originale shell Bourne (sh).

Lo scripting della shell è uno script in qualsiasi shell, mentre lo scripting di Bash è uno script specifico per Bash.

Il sistema operativo Linux offre diversi tipi di shell. Sebbene le shell abbiano molti comandi in comune, ogni tipo ha caratteristiche uniche. Studiamo diversi tipi di conchiglie per lo più usate.

Sh shell:

Sh shell è anche conosciuto come Bourne Shell. Sh shell è la prima shell sviluppata per computer Unix da Stephen Bourne ai Bell Labs di AT & T nel 1977. Include molti strumenti di scripting.

Bash shell:

La shell di Bash sta per Bourne Again Shell. Bash shell è la shell di default nella maggior parte della distribuzione Linux e sostitutiva di Sh Shell (la shell Sh verrà eseguita anche nella shell Bash). Bash Shell può eseguire la maggior parte degli script Sh shell senza modifiche e fornire anche la funzione di modifica della riga dei comandi.