C'è qualche garanzia che esista / usr / bin / env?


8

Spesso vedrò gli script iniziare con una riga shebang che utilizza #!/usr/bin/env interpreter_nameper qualsiasi interprete, con la logica che diversi sistemi potrebbero avere l'interprete di cui hanno bisogno per funzionare installati in luoghi diversi. Ad esempio, se suppongo che pythonsia installato come /usr/bin/pythonallora alcuni utenti che hanno deciso di installarlo come /opt/pythonper qualche motivo non saranno in grado di usarlo così facilmente.

Ma la domanda ovvia è: esiste una garanzia che envverrà installata in /usr/bin/env(o per quella parte in un determinato posto), o è solo un caso di "spostare il problema" per così dire?

Questa domanda leggermente correlata ha un commento che dice che è una cattiva idea ed è preferibile installarlo con il percorso effettivo dell'interprete e cita la singola specifica unix, ma in realtà non affronta questa domanda.

Risposte:


6

No, envnon è garantito che ci sia /usr/bin, come puoi leggere nella storia del meccanismo shebang , nella sezione "L'utilità env":

Tuttavia, la posizione di env (1) potrebbe variare. Le distribuzioni Free-, Net-, OpenBSD e alcune distribuzioni Linux (es. Debian) vengono solo con / usr / bin / env. D'altra parte, c'è solo / bin / env almeno su SCO OpenServer 5.0.6 e Cray Unicos 9.0.2 (sebbene quest'ultimo sia solo di interesse storico). Su alcune altre distribuzioni Linux (Redhat) si trova in / bin e / usr / bin / contiene un collegamento simbolico che punta ad esso.

Non sposta completamente il problema, a causa della flessibilità della envricerca $PATH. Se vi capita di ottenere alcuni script che utilizzano un percorso diverso per envdalla tua, è solo necessario conoscere dove i vostri envvite, e non anche il luogo dove perl, pythone altri interpreti potrebbe essere installato.

E non devi codificare /opt/python/3.3.2/bin/python3.3se questo è il primo python3.3eseguibile nel tuo PERCORSO. Puoi solo fare affidamento sul envtrovarlo, quindi non devi aggiornare tutti gli script se esegui l'aggiornamento per usare /opt/python/3.3.3/bin/python3.3. L'intestazione dello script rimane la stessa:

#! /usr/bin/env python3.3

Aha. Grazie. Non sono riuscito a trovare alcuna informazione al riguardo. Quando ho detto "spostare" il problema, intendevo che invece di cercare python perlecc., Ora devi solo dare la caccia env, quindi lo stesso problema, ma un obiettivo diverso. Sembra che envsia molto più facile da trovare, e ovviamente molto più versatile, quindi è ancora molto favorevole. Che risponde perfettamente alla mia domanda. Grazie!
scott_fakename
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.