2010-06-08 17 views
22

Mi chiedevo se è possibile creare un "link" in usr/bin (cioè) che conduce a uno script di shell.esecuzione di script di shell senza chiamare sh implicitamente

ma voglio solo scrivere

% shellscript 

invece di

% sh shellscript.sh 

un po 'come un alias.

È possibile?

+0

Ricordarsi della riga shebang come prima riga dello script per farlo funzionare –

+3

Tutti chiamano i propri script di shell .sh? Io * mai * uso un'estensione '.sh' sugli script, quindi ho sempre digitato semplicemente 'shellscript' –

+0

@Stephen P - Tendo a nominare il mio .sh (o .bash) se sono piccoli one off che io ' Ho solo bisogno di un paio di volte e corro dalla mia cartella home, ma rilasciamo l'estensione se ho intenzione di spostarli in una cartella bin e condividerli con altri utenti o usarli molto. – rjmunro

risposta

43

fare la prima riga dello script

#!/bin/sh 

Poi renderlo eseguibile digitando il comando:

chmod +x shellscript.sh 

Se ora si inserisce lo script in una cartella bin che è sul sistema di PATH variabile e sarete in grado di eseguirlo direttamente. Per visualizzare le cartelle nel percorso, digitare:

echo $PATH 

Io di solito uso /home/[my username]/bin per gli script che ho scritto in modo che non interferiscano con gli altri utenti del sistema. Se voglio che siano per tutti gli utenti, io uso /usr/local/bin che viene fornito vuoto sulla maggior parte delle distribuzioni.

Il .sh alla fine del nome file dello script è solo una convenzione per aiutarti a ricordare che tipo di file è. Funzionerà comunque se lo ridenominerai a shellscript, ad esempio, per completare i tuoi requisiti.

+0

Grazie per la tua descrizione dettagliata – ShoX

16

È possibile rendere eseguibile lo script della shell (chmod +x shellscript.sh). Quindi è possibile collegarlo a/usr/bin (ln -s shellscript.sh /usr/bin/shellscript).

+6

+1 per affermare in realtà come rendere il collegamento 'ln -s script .sh/usr/bin/script' –

2

Sì. È possibile utilizzare ln per creare un collegamento a shellscript.sh denominato shellscript. Sarà quindi necessario renderlo eseguibile, ma successivamente (supponendo che /usr/bin sia sul tuo percorso) puoi eseguirlo con shellscript.

+0

grazie per aver spiegato l'alternativa di collegamento! – ShoX

2

Oltre a rendere lo script eseguibile e il collegamento in/usr/bin, come altri hanno suggerito, si vuole anche aggiungere la riga "shebang" per la parte superiore dello script:

#!/bin/sh 

# your commands here 

Questo ti permette di specificare quale interprete di shell (bash, bourne shell, c-shell, perl, python ...) dovrebbe essere usato per eseguire il tuo script.

-1

Ho riflettuto su questa domanda sull'uso delle estensioni dei nomi in Unix/MacOSX e la risposta migliore che posso fornire è una copia dei miei commenti di sviluppo in un codice che ho scritto anni fa per automatizzare l'intero noioso processo di aggiornamento degli script che scrivo per l'inclusione in/usr/local/bin.

I have begun to 
change how I develop code for my contributions to 
/usr/local/bin. In the past I would always leave the development 
file without an extension and depend on the shebang 
#!/usr/bin/env ...) line. The flaw with using this approach 
exclusively is it does not allow me to utilize the code colorizing 
capabilities I have available for programming languages as deftly 
as I might. Also allot of development environments do not 
understand shebang and so see the code as plain text. Nor are the 
contents of files without file extensions accessible via the MacOSX 
QuickLook feature... 

In breve, il mio codice di automazione (piuttosto a molto per pubblicare qui) 'sudo' inserisce una copia eseguibile estensione-less del programma// local/bin usr ma il file nella directory di sviluppo mantiene è script/estensione del linguaggio programma in atto. Entrambe le copie hanno la stessa riga di shebang nella parte superiore del file.Una miriade di altri compiti ripetitivi sono automatizzati anche in questo codice di automazione. Ma la ricompensa finale è il "sovraccarico" associato al processo di scrittura di nuovi "comandi" o il tweaking dei comandi esistenti/usr/local/bin "ora prende una coppia di tasti.

Resto su Snow Leopard e resto diffidente nei confronti del Leone. Quindi se le cose sono diverse su Lion, mi scuso per qualsiasi confusione. Inoltre, se il tuo sistema operativo non ha l'equivalente di QuickLook, alcune cose che ho detto potrebbero andare perse, ma penso che qualsiasi utente Linux/Unix possa ancora trarre beneficio dal codice che si colorizza tramite il vim/less (http: // www- zeuthen.desy.de/~friebel/unix/less/README) comandi.

Un esempio di alcuni dei miei uscita codice standard colorizing automatico che facilita QuickLooking attraverso il codice nella directory di sviluppo:

/usr/bin/highlight --syntax sh --style neon -i "/Users/pcs/Projects /Shell/Bash/findpdftext/findpdftext.sh" >| "/Users/pcs/Projects/Shell /Bash/findpdftext/findpdftext.sh.html" 

Generazione di questo testo standard html mi costa nulla ed è più bella in QuickLook rispetto alle pagine man che sono generato automaticamente pure. Un altro piccolo esempio di output automatizzato che entra nello script nella directory di sviluppo del programma che verrà eseguito quando sono pronto a commettere eventuali modifiche allo script in questione alla copia "command" in/usr/local/bin:

##################################### REWIRE findpdftext.sh: 
chmod 777 "/Users/pcs/Projects/Shell/Bash/findpdftext/findpdftext.sh" 
cp -f "findpdftext.sh" "findpdftext" 
sudo ln -f "findpdftext" /usr/local/bin 
cp -f "findpdftext" "/Users/pcs/man/cat1/findpdftext.1" 

############### SYMBOLIC-LINK-NAMES supplied from command-line: 
##### fpdf is a symbolic link to findpdftext 
sudo ln -s -f "/usr/local/bin/findpdftext" "/usr/local/bin/fpdf" 
cp -f "/usr/local/bin/findpdftext" "/Users/pcs/man/cat1/fpdf.1" 

############### SYMBOLIC-LINK-NAMES supplied from command-line: 
##### fpt is a symbolic link to findpdftext 
sudo ln -s -f "/usr/local/bin/findpdftext" "/usr/local/bin/fpt" 
cp -f "/usr/local/bin/findpdftext" "/Users/pcs/man/cat1/fpt.1" 

In conclusione, per me ci sono motivi per utilizzare entrambi gli stili di denominazione dei file.

Problemi correlati