"Sh" deve trovarsi nella directory "/ bin"?

Ho letto che i sistemi operativi compatibili POSIX (ad esempio: Linux) devono avere la shshell.

Ma è necessario per shtrovarsi nella /bindirectory o può trovarsi in qualsiasi directory?

linux shell posix

— user270294
fonte

Puoi sempre usare un link simbolico poiché /bin/sh, nella maggior parte dei casi su Linux, è già un link simbolico a bash. È solo che molti script usano hardcoded/bin/sh

— cilgalad

Ora che hai la risposta che può vivere dove vuole, potresti chiederti: come puoi scrivere portabilmente una linea shebang sh? E la risposta è: shebang non fa parte di POSIX, quindi il problema non si presenta nemmeno.

— Jörg W Mittag,

@ JörgWMittag Sì, a volte è sorprendente quante delle cose che consideriamo funzionalità Unix "standard" non siano effettivamente richieste da POSIX.

— Barmar,

L'utilizzo o meno di uno shebang è indipendente dall'esistenza o meno del percorso /bin/shsu un sistema POSIX.

— Chepner,

Almeno su sistemi derivati da Ubuntu, /bin/shè presente un collegamento a dash. Sui BSD, /bin/shnon è un link ma un eseguibile separato, e certamente no bash.

— Rhialto sostiene Monica il

Risposte:

POSIX mandati solo la /deve /tmple directory di esistere , e la /dev/null, /dev/ttye /dev/consolefile. Le utilità standard devono esistere, ma non è stata specificata alcuna posizione specifica. Potrebbe non esserci /binaffatto a, e se esiste potrebbe non contenere a sh, e in caso contrario potrebbe non essere un POSIX sh.

È possibile ottenere una PATHvariabile valida che include gli strumenti POSIX, incluso sh, con il getconfcomando :

$ PATH=$(getconf PATH)
$ sh

Ciò può essere utile, ad esempio, su Solaris, dove l'impostazione predefinita shnon è compatibile con POSIX , ma shviene fornita una conforme e accessibile in questo modo (poiché Solaris è un Unix certificato ). getconf PATHincluderà /usr/xpg4/binnella parte anteriore, che contiene POSIX she una serie di altri strumenti richiesti ( inclusi quelli inutili comecd ).

— Michael Homer
fonte

Per quanto riguarda Solaris: ... a meno che non si stia eseguendo un'installazione "small server" di Solaris, che omette molti degli strumenti POSIX. Vedi unix.stackexchange.com/q/360359/135943

— Wildcard

Quelli "inutili"? Preferirei chiamarli ridondanti.

— Mukesh Sai Kumar,

come si trova getconf?

— Giosuè,

@MukeshSaiKumar un comando 'cd' autonomo non potrà mai funzionare

— OrangeDog

Bene, "funzionerà" solo per un valore di funzionamento che, per esempio, verifica se è possibile passare a una directory, ma in realtà non lascia il processo che l'ha chiamato lì. Questa è più funzionalità di nessuna, però.

— Charles Duffy,

No, non è necessario per shessere in /bin. Si cita in modo esplicito /bin, /usr/bine /usr/xpg4/bincome possibili sedi. Le specifiche POSIX richiedono solo che shsiano nel PERCORSO.

Le specifiche POSIX indicano :

Le applicazioni devono tenere presente che il PERCORSO standard sulla shell non può essere assunto come o /bin/sho /usr/bin/sh, e dovrebbe essere determinato dall'interrogazione del PERCORSO restituito da getconf PERCORSO, garantendo che il percorso restituito sia un percorso assoluto e non una shell incorporata.

Ad esempio, per determinare la posizione dell'utilità sh standard:

command -v sh

In alcune implementazioni ciò potrebbe restituire:

/usr/xpg4/bin/sh

— John1024
fonte

Come altri hanno già detto, questo non è strettamente necessario per la conformità POSIX.

Ma probabilmente la compatibilità con il software esistente è molto più importante (dopo tutto, lo scopo di POSIX è di far funzionare determinate cose su tutti i sistemi operativi conformi) e se un sistema operativo non fornisce sh /bin/sh, ciò romperà alcune cose.

Ovviamente, gli script che si #!/bin/shbasano su questo percorso vengono standardizzati. Questo non è necessario per funzionare; POSIX non richiede nemmeno che le #!linee siano supportate, anche se menziona che tale funzionalità è comune :

Un altro modo in cui alcune implementazioni storiche gestiscono gli script di shell è riconoscendo i primi due byte del file come stringa di caratteri "#!" e usando il resto della prima riga del file come nome dell'interprete dei comandi da eseguire.

Ma se ciò non è supportato, molti software esistenti si rompono o richiedono un lavoro aggiuntivo per il port.

— Ian D. Scott
fonte