Diversi modi di eseguire binari e script

Sto usando Linux da un po 'di tempo e ho cercato una panoramica completa di questo ma non ne ho trovato uno.

Semplicemente non riesco a fare i conti con tutti i diversi modi di eseguire script e binari: è tutto un gran casino per me e devo usare tentativi ed errori per determinare cosa dovrei usare. Per un file che è uno script o un file binario <script/binary>, posso trovare le seguenti alternative:

<script/binary>
. <script/binary>
./<script/binary>
source <script/binary>
sh <script/binary>

(Ce ne sono altri?)

Qualcuno può dare una panoramica completa di quali comandi funzionano con quali tipi di file e qual è la differenza quando ci sono più opzioni?

Grazie.

I seguenti comandi sono gli stessi, un componente punto significa "directory corrente". Per consentire l'esecuzione, i file devono disporre delle autorizzazioni eseguibili:

path/to/binary
./path/to/binary

Si noti che se un percorso non contiene una barra, viene trattato come un comando (o una shell incorporata o un programma che viene cercato nella $PATHvariabile d'ambiente).

Di seguito sono quasi uguali, eseguono uno script di shell (non binario!) Nell'attuale ambiente di shell. Una piccola differenza tra le due linee sono descritti in questa domanda Unix.SE .

. path/to/script
source path/to/script

Alla fine hai menzionato sh script. Ancora una volta, questo funziona solo per gli script di shell e non per i binari. Fondamentalmente stai eseguendo il shprogramma con il nome dello script come argomento. Nel caso sh, tratta semplicemente questo argomento come script di shell e lo esegue.

Per le risposte limitate agli script di shell, vedere Diversi modi per eseguire uno script di shell .

Grazie per tutti gli input. Cercherò di rispondere alla mia domanda ora e fornirò una guida completa alle diverse possibilità di eseguire script e binari. Modifica e commenta e saremo in grado di trovare qualcosa di completo e corretto. Ecco il mio suggerimento:

Inizialmente, due punti per affermare:

• Linux fa una distinzione tra un comando e un percorso . Un comando viene digitato così com'è sul prompt e eseguirà un built-in o farà sì che Linux cerchi un binario corrispondente o uno script sul $ PATH.

• Affinché Linux interpreti qualcosa come un percorso, deve contenere almeno una barra (/). Ad esempio ./myScript, ./può sembrare piuttosto ridondante - è lì solo per far interpretare Linux come un percorso piuttosto che un comando.

Quindi, le opzioni per eseguire un binario o uno script:

Esecuzione di un file binario binary:

$ binary          # when 'binary' is on the PATH, or is a built-in
$ ./binary        # when 'binary' is not on the path but in the current directory
$ /home/me/binary # when 'binary' is not on the PATH, and not in the current dir

Esecuzione di uno script script:

Il file dovrà disporre delle autorizzazioni di esecuzione se non diversamente specificato.

$ script        # execute a script that is on PATH. Will be executed in a new shell.
                # The interpreter to use is determined by the she-bang in the file.
$ ./script      # execute a script that is in the current dir. Otherwise as above.
$ /a/dir/script # when the script is not on the PATH and not in current dir. 
                # Otherwise as above.
$ . script      # execute a script in the current dir. Will be executed in the
                # current shell environment.
$ source script # equivalent to the above *1
$ sh script     # executes 'script' in a new shell *2 (the same goes for 'bash ...',
                # 'zsh ...' etc.). Execute permission not neccessary.

A proposito di lei :

Gli script con un botto (ad es. #!/bin/sh) Sulla prima riga indicano quale interprete usare.

• Questo interprete verrà usato quando eseguito da ./scripto usando un comando: script( scriptdeve essere sul PERCORSO)
• Usando sh scriptignorerà il botto e userà, in questo caso, shcome interprete
• Usare . scripto sourceignorerà il botto e usare l'interprete corrente (poiché .o sourceequivale a eseguire semplicemente ogni riga dello script nella shell corrente)

Le note

* 1: questo è solo quasi vero. In bash sono effettivamente lo stesso comando, ma quando si usano source, scriptsaranno cercati in $ PATH prima della directory corrente. Questo è bash, ma nelle shell solo POSIX, sourcenon funziona, ma .funziona. Quindi piuttosto usa quest'ultimo per la portabilità.

* 2: ciò che realmente accade è che eseguiamo sh binario con 'script' come argomento, il che renderà 'sh' eseguirà 'script' nella sua nuova shell

Ecco un breve elenco di comandi. Nota, quando menziono PATH, intendo le directory che contengono programmi che il sistema conosce; trovi quelli con echo $PATH, e sarà qualcosa del tipo:/home/mike/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games

Script

• Per eseguire uno script nella directory di lavoro corrente, utilizzare ./myscript.sh
• Per eseguire uno script su un altro file, utilizzare (se si trova nella directory di lavoro corrente), ./myscript.sh textfile.txt

• Gli script possono anche essere eseguiti con argomenti; come spiegato in Rute (p. 68): myfile.sh dogs cats birdsverrà emesso The first argument is: dogs, second argument is: cats, third argument is: birdsperché il contenuto di questo script dopo lo shebang è:echo "The first argument is: $1, second argument is: $2, third argument is: $3"

• Per eseguire uno script in un'altra directory, utilizzare ~/Scripts/dogs.sh

• Per eseguire uno script di cui il sistema è a conoscenza perché si trova nella cartella bin nella directory home (crearlo se non è presente, poiché verrà automaticamente aggiunto al PERCORSO), basta usare scriptname
• Per eseguire uno script che hai installato, usa nuovamente il suo nome, perché sarà noto al sistema: ad esempio, get_iplayer

Binari

• Per eseguire un file binario di cui il sistema è a conoscenza perché si trova in $ PATH, utilizzare il nome del programma e tutti i parametri, ad esempio, vlc <stream url to open>
• Per testare un binario che hai compilato prima di installare in / usr / local / bin, o per tenere un programma autonomo lontano dal sistema, usa ~/<folder>/app/myprog