2012-02-06 4 views
52

Se ho uno script di shell personalizzato o programmi, che ho creato da me o scaricato dal web e voglio essere in grado di eseguirlo dalla CLI, c'è la posizione standard per metterlo nella struttura di directory Linux/Unix?Directory standard Unix per mettere script o eseguibili personalizzati?

/usr/bin ? 
/usr/local/bin ? 
/usr/lib ? 
/usr/sbin ? 
/bin ? 
/sbin ? 
/var ? 

Di solito lo metto sotto la mia cartella ~/bin e lo metto in PERCORSO, ma non sembra pulito. E ogni volta che ho scaricato un nuovo programma, devo metterlo di nuovo nel PERCORSO.

+10

suggerisco 'uomo hier'. –

+4

Se il tuo ~/bin è sul PERCORSO, allora anche tutti i programmi che hai inserito in ~/bin dovrebbero essere sul tuo percorso ... Cosa vuoi dire che devi metterlo di nuovo sul PATH? – tpg2114

+0

Sono d'accordo con @ tpg2114, '~/bin' è un'ottima posizione per gli script della shell di proprietà dell'utente. –

risposta

67

/usr/local/bin esiste esattamente per questo scopo, per l'installazione a livello di sistema. Per il tuo uso privato, lo standard ~/bin è di fatto.

Se si desidera mantenere ciascun binario nella propria sottodirectory, è possibile farlo e aggiungere un collegamento simbolico a una directory già presente nello PATH. Così, per esempio

curl -o $HOME/downloads/fnord http://fnord.example.com/script.exe 
ln -s $HOME/downloads/fnord $HOME/bin/ 

fornito $HOME/bin è nel vostro PATH. (Ci sono strumenti come stow che fanno questo - e molto altro - dietro le quinte per voi.)

+2

Come suggerimento per gli utenti Mac: Se scegli "~/bin" e non vuoi che questa directory mostri il Finder, puoi renderla invisibile con [SETFILE (1)] (https://developer.apple). com/library/mac/documentation/Darwin/Reference/ManPages/man1/SetFile.1.html):'etetile -a V ~/bin' per rendere invisibili e file -et ~/bin' per renderlo nuovamente visibile. Nota che ciò richiede [Xcode Tools] (https://developer.apple.com/xcode/). – Henrik

+0

Grazie. Ricorda anche sbin per sudoers. – erm3nda

+0

@ triple: esiste una directory standard di fatto per gli script (bash, perl, ecc.)? Sto pensando ad es. ~/Etc? Il punto è che non si esegue il backup/traccia con un cvs/.. nello stesso modo degli script e dei binari. – phs

-9

Beh avrei usato ~/bin (mentre io non sono root), ma per quanto riguarda $PATH si può sempre fare

export PATH=".:${PATH}" 
# or 
export PATH="${PATH}:." 

In questo modo la directory di lavoro effettivo sarà sempre nella vostra $PATH. Sebbene abbia alcuni problemi di sicurezza ... specialmente con gli script scaricati.

+4

You non dovrebbe farlo, comporta un grande rischio per la sicurezza. Inoltre, cosa intendi per "ogni directory sarà nel tuo' $ PATH' "? –

+0

Sono d'accordo. Dovrebbe cercare tutte le directory per il tuo comando e potresti finire per eseguire qualcosa che non volevi, ecc. – CoffeeRain

+0

Hai ragione, ho modificato la mia risposta. –

16

Questo può variare leggermente a seconda del sapore Unix. Sto assumendo Linux qui (anche se questo potrebbe applicarsi a OSX). Secondo il (link ottenuto dal Linux Standard Base working group) Filesystem Hierarchy Standard (FHS):

La gerarchia /usr/local è per l'uso da parte dell'amministratore di sistema quando l'installazione del software in locale. Deve essere sicuro di essere sovrascritto quando il software di sistema viene aggiornato. Può essere utilizzato per i programmi e i dati condivisibili tra un gruppo di host, ma non trovato in /usr.

software installato localmente deve essere collocato all'interno /usr/local piuttosto che /usr meno che non sia in fase di installazione per sostituire o aggiornare il software in /usr.

/usr/local/bin è spesso sul percorso per impostazione predefinita.

Si noti che si deve solo mettere l'eseguibile o un collegamento ad esso in /usr/local/bin, il resto potrebbe dover andare in /usr/local/lib o /usr/local/share.

L'albero /opt potrebbe anche essere ragionevole:

/opt è riservato per l'installazione di add-on software applicativo pacchetti.

Un pacchetto da installare in/opt deve individuare i propri file statici in un separata /opt/<package> o /opt/<provider> directory albero, dove <package> è un nome che descrive il pacchetto software e <provider> è LANANA nome registrato del provider.

[...]

La directory/opt/bin,/opt/doc,/opt/include,/opt/info,/opt/lib, e/opt/uomo sono riservati ai locali uso dell'amministratore di sistema. I pacchetti possono fornire file "front-end" destinati a essere inseriti (tramite collegamento o copia ) da queste directory riservate dall'amministratore di sistema locale, ma devono funzionare normalmente in assenza di queste directory riservate .

(Si potrebbe fare il vostro proprio collegamento da /opt/your-package/bin/executable in /opt/bin, e mettere /opt/bin sul PATH se non è già presente.)