Perché gli script definiscono comandi comuni nelle variabili?

Question

Vedo questo tutto il tempo al mio posto di lavoro:

#!/bin/sh 

..... 

CAT=/usr/bin/cat         # An alias for cat 
MAIL=/usr/bin/mail        # An alias for mail 
WC=/usr/bin/wc         # An alias for word count 
GREP=/usr/bin/grep        # An alias for grep 
DIRNAME=/usr/bin/dirname       # An alias for dirname 
RM=/usr/bin/rm         # An alias for rm 
MV=/usr/bin/mv         # An alias for mv 

..... 

è solo la mia azienda che fa questo? C'è una ragione per cui vorresti precisare dove sono questi comandi estremamente comuni? Perché dovrei voler $CAT fare riferimento a /usr/bin/cat quando cat fa già riferimento a /usr/bin/cat? Mi sto perdendo qualcosa? Sembra inutilmente ridondante.

Answer 1

L'utilizzo del percorso completo garantisce che lo script funzioni correttamente anche se è gestito da un utente che personalizza la sua variabile di ambiente PATH in modo che trovi versioni diverse di questi comandi rispetto a quanto previsto dallo script.

L'utilizzo delle variabili semplifica la scrittura dello script, pertanto non è necessario scrivere il nome percorso completo di un comando ogni volta che viene visualizzato nello script.

Answer 2

Benvenuti nell'azienda dove nulla è dato per scontato.

Questi sono comunemente definiti per garantire la versione corretta o per imporre l'installazione di env in più caselle.

https://github.com/torvalds/linux/blob/master/tools/scripts/Makefile.include#L15

questo modo è possibile verificare se esiste dir.

Answer 3

È solo la mia azienda che fa questo?

No.

C'è un motivo per cui si vuole precisare dove questi comandi estremamente comuni sono?

Sì.

perché dovrei $CAT per riferirsi a/usr/bin/gatto quando cat si riferisce già a /usr/bin/cat?

Sei sicuro cat si riferisce sempre alla /usr/bin/cat? Cosa succede se il tuo script viene eseguito in un ambiente in cui c'è un diverso cat prima nel percorso? O dove c'è semplicemente una directory controllata dall'utente in precedenza nel percorso, dove un utente può installare un comando canaglia cat? Se il tuo script dovesse mai essere eseguito con privilegi elevati, allora vuoi davvero dare agli utenti a caso la possibilità di fare tutto ciò che vogliono sul tuo sistema?

Sei sicuro che cat è supposto fare sempre riferimento a /usr/bin/cat? Se mai lo script fosse installato in un ambiente in cui era necessario un diverso cat (ad esempio /usr/local/bin/gnucat), allora preferiresti modificare una riga o venti?

Mi manca qualcosa? Sembra inutilmente ridondante.

Sì, ti manca qualcosa.

Si vorrebbe evitare di scrivere fuori /usr/bin/cat ovunque si desidera eseguire cat, e si vorrebbe essere in grado di scegliere un diverso cat dove necessario (o più probabilmente un diverso make o grep o sed). D'altra parte, si vuole evitare l'influenza esterna potenzialmente pericolosa sul comportamento di uno script affidabile. Definire il percorso completo per il comando in una variabile di shell e quindi utilizzare tale variabile per eseguire il comando realizza questi obiettivi.

Answer 4

Un modo per evitare questo e avere ancora la sicurezza di ignorare l'ambiente dell'utente è quello di precisare esplicitamente le variabili nello script

#!/bin/sh 

PATH=/bin:/usr/bin # maybe you need something in /usr/sbin, add that 
LC_ALL=C    # ignore the user's locale 
LD_LIBRARY_PATH=something # or unset it if you want nothing 

# then 
cat /a/file   # have confidence you're using /bin/cat 

Ci possono essere altri: controllare le pagine man dei programmi usa nel tuo codice.