Perché nessuno usa la vera shell Bourne come / bin / sh?


55

Ho notato che praticamente nessun sistema con cui abbia mai lavorato ha /bin/shun vero eseguibile. È sempre un collegamento simbolico a dash, bashin modalità POSIX o qualcosa di simile.

Perché? Quali sono gli svantaggi dell'utilizzo del vero, originale /bin/sh? (Velocità? Licenze?)


3
Hai mai usato solo Linux, vero? Ho sempre visto "sh come symlink" su Linux.
Greg Hewgill,

@GregHewgill Le versioni recenti di Solaris non hanno un shlink simbolico ksh?
Gilles 'SO- smetti di essere malvagio' il

1
@Gilles secondo una delle risposte, sì, dal momento che Solaris 11. è collegato ksh.
strugee,

1
@GregHewgill Ho anche usato Darwin, che ha un link simbolico a bashIIRC.
strugee,

6
Cosa intendi per originale / bin / sh ? La shell Thomson di Unix V1? La shell Bourne di Unix V7 che non aveva funzioni non commenti ...? Quello in SysIII, SysV, Solaris, HP / UX, la reimplementazione della cenere sui BSD? Al giorno d'oggi shsi basa su uno standard, il che significa che possiamo avere diverse implementazioni che si comporteranno in un modo chiaramente specificato purché utilizzi la sintassi standard nel tuo script.
Stéphane Chazelas,

Risposte:


38

Immagino la mancanza di funzionalità: nessuna cronologia dei comandi, nessun reindirizzamento di fantasia, nessuna modifica della riga di comando. BSD ha introdotto cshla shell C per questi motivi. Un altro fattore è che la Bourne Shell originale era disponibile solo di recente in forma open source . A meno che non sia stato concesso in licenza, non è possibile distribuirlo. Ciò lo ha reso fuori portata per distribuzioni gratuite e lo ha reso ideologicamente sgradevole per altre distribuzioni e * BSD.

Ma il codice è ora disponibile . Puoi dare un'occhiata, compilarlo, provarlo.


50
E poi prontamente tornare a quello che stavi usando prima.
Ignacio Vazquez-Abrams,

24
@strugee "" mancanza di funzionalità "- perché questo dovrebbe essere un problema?" Sì, buon punto ... perché i programmatori usano cose inutili come assembly / C / linguaggi di alto livello quando tutto ciò che puoi fare con loro puoi già scrivere linguaggio macchina direttamente? Il fatto è: caratteristiche = aumento della velocità di sviluppo + maggiore manutenibilità = meno costi = migliore L' uso shè esattamente come l'uso, bashtranne per il fatto che: più lento, i programmi sono più lunghi ed è più difficile da mantenere.
Bakuriu,

10
Non è proprio la mancanza di funzionalità, ma il fatto POSIX impone il shcomando di eseguire una shell conforme POSIX, cosa non è la shell Bourne legacy. Mentre POSIX non richiede shdi essere in /bin/sh, questa è la directory più logica per essere.
jlliagre,

4
La cronologia dei comandi di @Bakuriu e la modifica della riga di comando sono entrambe cose di cui non avresti davvero bisogno per uno script.
Strugee,

4
@strugee Quelle non sono le uniche differenze. Ad esempio shnon ha espansione di tilde e parentesi graffe, mancano alcuni built-in (ad esempio pushde popd, select) nessuna espansione aritmetica. Manca un sacco di variabili, ad es PIPESTATUS.
Bakuriu,

23

L'affermazione nella tua domanda non è corretta. Solaris fino alla versione 10 è fornendo l'eredità vera shell Bourne come /bin/sh. Ciò è stato fatto per non interrompere la compatibilità con vecchi script che potrebbero non riuscire con una shell diversa. Questa scelta è stata comunque molto frustrante.

La maggior parte se non tutte le versioni Unix e Unix rimanenti, incluso Solaris 11, forniscono una shell POSIX compatibile /bin/shpoiché POSIX impone il shcomando di avviare una shell POSIX, non la shell Bourne legacy che non è conforme. /bin/shè generalmente:

  • ksh88o ksh93sulle implementazioni commerciali di Unix
  • un modificato bashsu OS/X(anche se prima zsh)
  • uno asho pdkshderivato su altroBSDs
  • basho dashsu distribuzioni Gnu / Linux.

Non è necessariamente un collegamento, ma può essere un vero eseguibile su molti sistemi ma su Gnu / Linux.

È interessante notare che, nonostante ciò che afferma la risposta più votata alla tua domanda, non è la mancanza di funzionalità che inducono gli sviluppatori di distribuzione a installare qualcosa di diverso dalla shell Bourne legacy, /bin/shma il desiderio di essere il più possibile conforme POSIX, vale a dire comportarsi come un Unix come OS. Il fatto che la shell POSIX abbia più funzionalità rispetto alla precedente shell Bourne è solo un effetto collaterale di questo obiettivo di conformità standard.

È anche un dato di fatto che alcune shell, in particolare bash, si comportano diversamente quando vengono chiamate sh, e questo rimuove principalmente le funzionalità dalla shell, non viceversa.


16

Per quanto ne so, la shell Bourne originale non poteva essere utilizzata dai BSD e dal progetto GNU, a causa della sua licenza.

All'epoca la versione originale di Unix non aveva licenza e il progetto GNU aveva bisogno di una shell che era sotto GPL, quindi usarono la bash.

Lo stesso vale per BSD4, il genitore di tutti i BSD. Grazie alla causa AT&T avevano bisogno di riscrivere tutte le fonti dall'unico Unix inclusa la shell Bourne.

Nella tradizionale linea BSD, la shell Bourne è stata spedita fino a 4.3BSD-Reno (ma non più con Net / 2 e i seguenti 4.4BSD). Per motivi di licenza è stato quindi sostituito con lo sh bourne-compatibile, simile a svr4 da Kenneth Almquist (spesso chiamato cenere).

Da FreeBSDs man sh

Un comando sh, la shell Thompson, è apparso nella versione 1 AT&T UNIX. È stato sostituito nella versione 7 AT&T UNIX dalla shell Bourne, che ha ereditato il nome sh.

Questa versione di sh è stata riscritta nel 1989 con licenza BSD dopo la shell Bourne di AT&T System V Release 4 UNIX

Quindi entrambi i progetti sono stati costretti a non usare la shell Bourne e accontentarsi di una vera shell open source.


7

Ci sono stati altri problemi. Bourne Shell ha usato sbrk () invece di malloc () e questo non lo ha reso molto portatile.

Dopo che Bourne Shell è diventato OpenSource tramite OpenSolaris, ho creato una versione portatile hafway e successivamente una versione davvero portatile sostituendo sbrk () con malloc () con l'aiuto di Geoff Collyer (la stessa persona che ha aiutato a evitare sbrk () nel Korn Shell).

Il motivo iniziale, per cui ho realizzato una versione portatile della Bourne Shell, è che mi è piaciuto rendere l'Editor della storia che ho scritto per il mio "bsh" tra il 1982 e il 1984 disponibile anche nella Bourne Shell. Nel frattempo, ho portato la maggior parte delle caratteristiche uniche che ho scritto per "bsh" su Bourne Shell.

Questo è tra gli altri:

  • Compila e funziona quasi ovunque, incluso Cygwin (quasi 2 volte più veloce di bash)
  • L'editor di cronologia con un buffer ad anello LRU
  • TERMCAP incorporato
  • Alias ​​avanzati (alias persistenti globali, alias locali, ....) e insieme al built-in "dosh", Bourne Shell è l'unica implementazione simile a Bourne Shell che consente alias parametrizzabili.
  • Supporto per modificare alias complessi nell'editor cronologico in modalità raw.
  • Accedi a tutti i 32 bit del codice di uscita (2) tramite variabili .sh. *.
  • timing automatizzato avanzato con risoluzione a 6 cifre
  • pushd / popd / dirs
  • builtin "trova"
  • Pipe da stderr
  • Utilizzo di vfork () per prestazioni migliori.
  • infine risolti tutti i bug documentati dalla shell Bourne SVr4, ad es. suspend funziona sempre in modalità controllo lavoro. ...

La pagina man online è disponibile all'indirizzo: http://schillix.sourceforge.net/man/man1/bosh.1.html Le fonti fanno parte della toolbox schily su:

https://sourceforge.net/projects/schilytools/files/

Consiglio di utilizzare: http://sourceforge.net/projects/schilytools/files/schily-2015-08-18.tar.bz2 o una versione più recente.

PS Sono interessato al feedback


Ciao Joerg. Perché portarli sulla shell Bourne piuttosto che su una shell che era già stata POSIXificata come un BSD sh o pdksh?
Stéphane Chazelas,

Il porting di Bourne Shell è stata una sfida in quanto non utilizza stdio. Questa è stata una sfida simile a quella di prendere la fonte csh originale e farla compilare sostituendo la stampa non stdio scritta nell'assemblatore VAX. Ma ho già aggiunto molte nuove funzionalità POSIX alla Bourne Shell e mi piace stare con la Bourne Shell su SchilliX per consentirgli di avviarsi con / anr / usr su filesystem separati che non è possibile con Korn Shell.
schily,

Inoltre, ho voluto verificare che la velocità di ksh sia causata dall'uso di vfork (). Ora che ho convertito Bourne Shell in vfork () è esattamente veloce quanto le recenti versioni di ksh. Questa è un'esperienza che si ottiene solo quando si inizia con il codice sorgente Bourne Shell originale.
schily,

OK, ma fino a quando non renderai conforme questo sh POSIX, è probabile che non attiri molto interesse. Ricordo che hai chiesto al gruppo ML di Austin delle incompatibilità con POSIX della shell Bourne, è qualcosa su cui stai lavorando (il che significherebbe interrompere la retrocompatibilità con la shell Bourne)? Anche le persone (almeno io) considerano la sintassi sh POSIX un progresso sulla shell Bourne. Continuando a chiamare la shell derivata da Bourne, la shell Bourne può inviare un'impressione sbagliata. Che ne dici di bimsh (Bourne migliorato (ala vi / vim))?
Stéphane Chazelas,

La mia Bourne Shell è già migliore di ksh in alcuni aspetti, ad esempio implementando alias migliori, pushd / popd / dirs e supporto all'utilizzo delle risorse basato sulle moderne funzionalità UNIX invece se ciò che fa ksh che è ancora basato su SVr2. Dato che sembri interessato e esperto nella shell, vorrei avere idee su cosa vorresti vedere dopo nella Bourne Shell dopo aver letto: schillix.sourceforge.net/man/man1/bosh.1.html Nota che finora, ho tutto il nuovo codice # ifdef'd e alcune funzioni (come le pipe stderr) devono essere attivate tramite set (1).
schily,

4

È collegato a shell che forniscono una compatibilità all'indietro al 100% . Non perdi nulla della shell originale ma ottieni più funzionalità. Non ci sono aspetti negativi, quindi perché perdere le nuove funzionalità? Questo è lo stesso motivo per cui di /bin/visolito è collegato a VIM .


5
L'aspetto negativo è che le persone scrivono script che funzionano sul loro unico sistema, pensando che i loro script siano compatibili quando non lo sono. Una volta ho corretto quasi un centinaio di script di shell Gentoo che in realtà richiedevano bash ma si chiamavano / bin / sh. Si sono tutti rotti quando ho cambiato / bin / sh per essere dash anziché bash.
Zan Lynx,

3
"no downside" - velocità. per esempio bashè molto, molto più lento didash
strugee

@strugee Se stai cercando la velocità di miglioramento della gamma ms in una shell, probabilmente non stai usando lo strumento giusto per il lavoro.
Chris Down,

1
@ChrisDown definisce "miglioramenti dell'intervallo ms"?
Strugee,

2
La sintassi sh POSIX non è completamente retrocompatibile con la sintassi sh Bourne. Ad esempio, IFS=,; rm file1,file2,file3rimuoverebbe quei 3 file nella shell Bourne. Quella (stupida) funzionalità è stata rimossa in POSIX sh. Esistono dozzine di sottili differenze che potrebbero far funzionare diversamente uno script scritto per la shell Bourne con un sh POSIX.
Stéphane Chazelas,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.