Dove si trova un buon posto permanente per installare script bash personalizzati?

32

Sto per installare "leiningen" che è uno script bash per il linguaggio di programmazione clojure con molta utilità ... ... ma non sono sicuro di dove sia appropriato -put- uno script eseguibile in Linux sistema in modo che sia disponibile in modo permanente e stabile.

Non penso che abbia senso in qualsiasi punto di / home, ma non so quale directory / directory dovrebbero essere usate per questo.

/ Usr / share?

— Kzqai
fonte

1

pathname.com/fhs/pub/fhs-2.3.html

— Ignacio Vazquez-Abrams

45

(Nota: si ~traduce come /home/userin questo post)

Personalmente, ho inserito tutti i miei script di sistema personalizzati /usr/local/bine tutti i miei script bash personali ~/bin. Pochissimi programmi che installo si posizionano nella /usr/local/bindirectory, quindi non è molto ingombra ed era già nella $PATHvariabile sulla maggior parte delle mie macchine.

Per aggiungere /usr/local/binal tuo percorso di sistema (se non è già presente) aggiungi questo a /etc/profile:

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

Per aggiungere ~/binal percorso dell'utente aggiungi questo a ~/.bash_profile:

PATH=$PATH:$HOME/bin
export PATH

A volte il default .bash_profilefile avrà un'istruzione if che aggiunge automaticamente ~/bina $PATHse esiste, in modo da creare l' ~/bine aprire un nuovo terminal per vedere se il vostro fa già questo.

— Trey Hunner
fonte

I BSD lo fanno per impostazione predefinita.

— Chris S,

@Chris: i BSD hanno messo un sacco di roba in / usr / local / bin

— Dan Andreatta

Qual è la differenza tra i tuoi script bash e quelli di sistema, e c'è un motivo per separarli?

— Hashim,

@Hashim Non posso parlare per Trey ovviamente, ma gli strumenti che sviluppi per le tue esigenze personali tendono a "laurearsi" in strumenti di sistema quando noti che risolvono un problema con cui altri stanno lottando, o hai un'altra installazione a livello di sistema che dipende su uno di questi strumenti. Sospetto che la soglia per l'installazione di qualcosa a livello di sistema sia piuttosto elevata per la maggior parte dei programmatori. Inoltre, uno strumento che condividi deve avere documentazione ecc. Che raramente molti sviluppatori scrivono diversamente.

— Tripleee

A parte questo, non c'è bisogno di exportuna variabile più volte (e probabilmente il tuo sistema è già contrassegnato PATHper l'esportazione, quindi non devi farlo da solo).

— Tripleee

9

/ usr / local / è davvero il posto giusto, mentre / opt è davvero per applicazioni di terze parti; "/ opt è riservato per l'installazione di pacchetti software applicativi aggiuntivi." Questo fa parte del Filesystem Hierarchy Standard.

Vedi http://www.pathname.com/fhs/pub/fhs-2.3.html per la discussione su / opt.

Per / usr / local /, è per "uso da parte dell'amministratore di sistema". Basta non dimenticare le cose lì dentro - documentale.

— Jamieson Becker
fonte

Il link che hai fornito dice "Le directory / opt / bin, / opt / doc, / opt / include, / opt / info, / opt / lib e / opt / man sono riservate all'uso dell'amministratore di sistema locale". Non c'è nulla su / usr / local. Qui è menzionato solo / usr / local / share. D'altra parte, i programmi compilati sono generalmente installati in / usr / local su Linux. Non pensi che / opt / bin sia il posto migliore per l'uso da parte dell'amministratore di sistema?

— raacer,

1

@raacer La mia esperienza è che /usr/local- come suggerisce il nome - è per l'amministratore locale e /optper cose che non sono ufficialmente distribuite, come software commerciale di terze parti che è gestito da un processo simile (potrebbe essere sostituito o cancellato in un aggiornamento da upstream) ma non gestito dal gestore dei pacchetti della distro, o forse effettivamente distribuito come RPM o .debpacchetti, ma non organizzato e impacchettato in conformità con tutte le politiche e convenzioni della distro.

— Tripleee

1

@raacer C'è una sezione separata interamente più /usr/localavanti nel documento.

— Tripleee

@raacer tripleee ha ragione. Ecco il link: pathname.com/fhs/pub/… .. corretti, programmi compilati (di solito open source) che sono compilati / costruiti appositamente per quel sistema o condivisi tra più sistemi (ma non fanno parte del normale packaging / distribuzione del SO, ma che dipendono fortemente dalle librerie condivise) dovrebbe essere installato in / usr / local (sostanzialmente rispecchia la gerarchia di / usr). I software di terze parti compilati su un sistema possibilmente diverso con possibilmente il proprio supporto di libreria (ad esempio, firefox, userify) dovrebbero andare in / opt.

— Jamieson Becker,

3

Storicamente useresti qualcosa come / opt. Tutto va bene purché sia aggiornato in $ PATH per gli utenti che dovrebbero averlo (quindi qualsiasi cosa in / home è una cattiva idea).

— Tony
fonte

2

/usr/share/clojuresembra un luogo comune dove mettere i binari e le librerie di clojure - perché non lo so, sembra naturale per /usr/local/share/clojure- quindi creare una sitesottodirectory in questo per questi script bash sembra a posto.

Il punto generale è che ha più senso organizzare gli script per funzione, non avere tutti gli script bash nello stesso posto.

— Charles Stewart
fonte

1

Ci sono un paio di problemi nell'usare /usr/sharequesto. Innanzitutto sharesignifica file indipendenti dall'architettura (cioè condivisi tra architetture). Per questo motivo le librerie e gli eseguibili non appartengono a una sharedirectory. In secondo luogo, tranne /usr/localche altro che il gestore dei pacchetti di distribuzione dovrebbe mai scrivere /usr.

— Kasperd,

2

/usr/local, Credo che ci sia un po 'di confusione nel significato di "locale".

A quanto ho capito, "locale" non significa "originato dalla / dalla macchina locale" ma, più semplicemente, "specifico della macchina locale", che può o non può provenire dalla / dalla macchina locale.

— Hatebit
fonte