Esecuzione di script da un'altra directory


11

Abbastanza spesso, lo script che voglio eseguire non si trova nella mia directory di lavoro corrente e non voglio davvero lasciarlo.

È buona norma eseguire script (BASH, Perl ecc.) Da un'altra directory? Di solito troveranno tutte le cose di cui hanno bisogno per funzionare correttamente?

In tal caso, qual è il modo migliore per eseguire uno script "distante"? È

. /path/to/script

o

sh /path/to/script

e come usare sudoin questi casi? Questo, ad esempio, non funziona:

sudo . /path/to/script

Essere consapevoli del fatto che . /path/to/script fonti la sceneggiatura! Non hai bisogno del periodo se vuoi solo eseguirlo.
gniourf_gniourf

Risposte:


14

sh / path / to / script genererà una nuova shell ed eseguirà lo script indipendentemente dalla shell corrente. Il sourcecomando (.) Chiamerà tutti i comandi nello script nella shell corrente. Se exitad esempio lo script chiama , allora perderai la shell corrente. Per questo motivo di solito è più sicuro chiamare gli script in una shell separata con sh o eseguirli come binari usando il percorso completo (che inizia con /) o relativo (./). Se chiamati come binari, verranno eseguiti con l'interprete specificato (#! / Bin / bash, ad esempio).

Per sapere se uno script troverà o meno i file di cui ha bisogno, non c'è una buona risposta, se non guardare lo script per vedere cosa fa. Come opzione, puoi sempre andare alla cartella dello script in un processo secondario senza lasciare la cartella corrente:

$(cd /wherever/ ; sh script.sh)

3
Intendi (cd /wherever/ ; sh script.sh)? Perché hai un $davanti?
G-Man dice "Reinstate Monica"

7

Puoi sicuramente farlo (con le modifiche che gli altri hanno menzionato come sudo sh /pathto/script.sho ./script.sh). Tuttavia, faccio una delle poche cose per farli funzionare a livello di sistema per non preoccuparmi di dirs e risparmiarmi inutili digitazioni extra.

1) Collegamento simbolico a /usr/bin

ln -s /home/username/Scripts/name.sh /usr/bin/name

(assicurati che non ci sia un nome sovrapposto lì, perché ovviamente lo sovrascriveresti.) Questo mi permette anche di tenerli nelle mie cartelle di sviluppo in modo da poterlo aggiustare se necessario.

2) Aggiungi la directory Script al tuo percorso (usando .bash_profile - o qualunque altro. Profilo che hai sulla tua shell)

PATH=/path/to/scripts/:$PATH

3) Crea Alias ​​in .bash_profile in ~/.bash_profileaggiungi qualcosa come:

alias l="ls -l"

Come puoi dire, la sintassi è solo un alias, cifre che vuoi agire come un comando, il comando. Quindi digitando "l" in qualsiasi punto del terminale si otterrebbe ls -l Se si desidera sudo, basta alias sl="sudo ls -l"notare a se stessi l vs sl (come esempio inutile).

Ad ogni modo, puoi semplicemente digitare sudo nameofscripted essere sulla buona strada. Non c'è bisogno di scherzare con ./ o. o sh, ecc. Prima contrassegnali come eseguibili: D


Consiglio vivamente l'opzione 2.
Bernhard,

Perché ?, è una buona pratica o solo gusto?
Sergio,

3

Di solito faccio come dici tu

sh /path/to/script

E per eseguirlo come root / superutente

sudo sh /path/to/script

La tua directory attuale conta solo se gli script presuppongono che tu sia nella stessa cartella. Suppongo che la maggior parte degli script non lo faccia e tu sei salvato per eseguirlo come sopra.


non funzionerebbe se secure_path è impostato nel file / etc / sudoers
l1zard

3

Di solito tengo i miei script in ( /usr/local/bino /usr/local/sbin/se lo script ha bisogno dei privilegi di root) a cui appartengono, secondo il Filesystem Hierarchy Standard (FHS).

Tutto quello che devi fare è assicurarti che queste due directory siano aggiunte alle tue PATH. Puoi farlo modificando il tuo $HOME/.bashrcfile e aggiungendo questa riga:

export PATH=$PATH:/usr/local/sbin:/usr/local/bin

Se vuoi essere in grado di eseguire uno script come root tramite sudo, devi aggiungere queste directory alla variabile secure_pathnella tua /etc/sudoers.

Defaults    secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

La modifica di questo file viene eseguita eseguendo in modo da visudonon avere errori.


Errore di battitura: intendi .bashrcinvece di .bachrc.
gniourf_gniourf

0

Non sono sicuro che funzioni così in Linux, supponendo che non lo faccia se nessuno lo ha suggerito. Ma invece di usare ././ per tornare indietro alle directory. Puoi usare le virgolette per dargli un percorso assoluto? Forse non ti dà accesso a tutto il disco per essere nemmeno in grado di farlo che effettivamente ci viene in mente.


0

Se hai degli script in giro che devi eseguire spesso e dipendono dalla loro posizione per trovare le risorse, puoi farlo facilmente combinando i comandi in un alias come questo.

alias run-script="cd /home/user/path/to/script/ && bash script.sh"

In questo modo non devi modificare nient'altro per farlo funzionare.


0

Non so perché nessuno l'abbia suggerito, ma è semplicissimo! Ho cercato su Google alcune volte e non sono riuscito a trovare questa risposta esatta, quindi ho pensato di condividere. IMO, questa ma la soluzione migliore, anche la più semplice, per me comunque, comunque altri potrebbero sentire e fare le cose in modo diverso.

# Place this somewhere in your .bashrc/.bash_profile/etc and edit as you see fit

YOURCOMMAND () {
  cd /path/to/directory/containing/your/script/ && ./YOURSCRIPT
}

Innanzitutto il comando "cd" indica la directory della posizione degli script. Quindi '&&' in modo da poterlo legare dopo aver eseguito il comando successivo. Finalmente apri il tuo script proprio come lo eseguiresti all'interno del terminale! Hai salvato il tuo file BASH e l'installazione richiede 5 secondi.

Spero che questo abbia aiutato qualcuno.


-1

Domanda antica, ma senza tempo.

La soluzione che ho sempre visto è quella di avere una $HOME/bindirectory e metterla per prima $PATH(tramite ~/.bashrcse non è già presente; su alcuni sistemi ~/binè la prima in $PATHper impostazione predefinita). Eliminare gli script lì per l'esecuzione o i collegamenti simbolici agli script / eseguibili altrove è il modo semplice per gestire i problemi di percorso che non dovrebbero influire sul sistema o su altri utenti.

Se uno script richiede risorse aggiuntive che possono essere trovate relativamente alla propria posizione (non insolita), $BASH_SOURCEviene utilizzato envvar . $BASH_SOURCEcontiene sempre il percorso assoluto dello script attualmente in esecuzione stesso, indipendentemente dal valore di $PWD.

Considera quanto segue:

ceverett@burrito:~$ echo $PATH
/home/ceverett/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games

Quindi possiamo vedere che $HOME/binè il primo $PATH, quindi tutto ciò che ho inserito ~/binverrà eseguito. Ho uno script dimostrativo chiamato ~/bin/findme:

#!/bin/bash

echo "Running from $BASH_SOURCE"

Questo può essere usato per ottenere il percorso assoluto verso la posizione dello script in esecuzione.

ceverett@burrito:~$ findme
Running from /home/ceverett/bin/findme
ceverett@burrito:~$ cd foo
ceverett@burrito:~/foo$ findme
Running from /home/ceverett/bin/findme
ceverett@burrito:~/foo$ cd /
ceverett@burrito:/$ findme
Running from /home/ceverett/bin/findme

(1) Mentre queste sembrano essere informazioni utili, la domanda non ha posto le domande su come scrivere script che utilizzano risorse relative alla propria posizione; ha chiesto di eseguire script. (2) Non sono sicuro di come il tuo secondo paragrafo affronti la domanda. Stai suggerendo che, se scrivo una sceneggiatura e Desmond vuole eseguirla, dovrebbe collegarla alla sua bindirectory privata ? Sembra ingombrante. (3) Inoltre, rompe l'indipendenza della posizione. Se /home/desmond/bin/fooè un link al mio script, BASH_SOURCElo sarà /home/desmond/bin/foo, e lo script non sarà in grado di trovare le sue risorse.
G-Man dice "Reinstate Monica"

@ G-Man (1) L'utente non ha fornito molto contesto. Ogni volta che questa domanda mi è stata posta negli ultimi 30 anni è sempre stato nel contesto di un utente (di solito un nuovo sysop o sviluppatore) che eseguiva un mix di script propri e di altri acquisiti per automatizzare attività banali, quindi ho risposto che modo. Questo fa assumere un po 'di conoscenza di scripting da parte del richiesto dall'utente. (2) Gli script di sistema sono generalmente installati in /bino in una posizione nota in /opt. (3) L'indipendenza dell'ubicazione è esattamente ciò che preserva quando si scrive una raccolta interdipendente di script personali.
zxq9,
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.