it-swarm.it

Che cos'è / usr / local / bin?

Prima di oggi, ho usato il terminale in misura limitata per spostarmi dentro e fuori dalle directory e cambiare le date dei file usando il comando touch. Avevo realizzato l'intera estensione del terminale dopo aver installato uno script divertente su Mac e aver dovuto chmod 755 Il file per renderlo eseguibile in seguito.

Vorrei sapere che cos'è /usr/local/bin. /usr/, Presumo, è l'utente del computer. Non sono sicuro del motivo per cui /local/ È lì, però. Ovviamente rappresenta il computer locale, ma dal momento che si trova sul computer (o su un server), sarebbe davvero necessario? /usr/bin Non andrebbe bene?

E cos'è /bin? Perché questa area viene solitamente utilizzata per l'installazione di script sul terminale?

93
JFW

/usr/local/bin è per i programmi che un normale utente può eseguire.

  • Il /usr/local la gerarchia deve essere utilizzata dall'amministratore di sistema durante l'installazione del software in locale.
  • Deve essere sicuro di non essere sovrascritto quando il software di sistema viene aggiornato.
  • Può essere utilizzato per programmi e dati condivisibili tra un gruppo di host, ma non trovato in /usr.
  • Il software installato localmente deve essere inserito in /usr/local anziché/usr a meno che non sia installato per sostituire o aggiornare il software in /usr.

Questa fonte aiuta a spiegare standard di gerarchia dei filesystem a un livello più profondo.

Potresti trovare questo articolo sull'uso e l'abuso di /usr/local/bin anche interessante.

82
iamsid

/ usr /, presumo sia l'utente del computer.

Vicino.

Unix è iniziato come un sistema operativo multiutente, quindi non è "l'utente", è "il utenti," plurale.

Prima che AT&T Unix System V Release 4 (SVR4) uscisse nel 1988 con i suoi strumenti di gestione utenti predefiniti nella creazione di home directory utente in /home, la posizione convenzionale era /usr. ¹ Il tuo $HOME directory potrebbe essere stata /usr/jfw su una casella Sistema III .

/usr conteneva anche, quindi come ora, /usr/bin, /usr/lib, ecc. L'esperienza ha dimostrato che segregare le home directory era una buona pratica di gestione del sistema, quindi con /home cambio di politica in SVR4, ha lasciato alle spalle tutto ciò che ora pensiamo appartenga a /usr.

/usr aveva ancora una buona ragione per mantenere il nome: ciò che restava indietro erano i file che non dovevano essere disponibili fino a quando il sistema non fosse stato avviato abbastanza da supportare il normale uso interattivo. Vale a dire, ciò che è stato lasciato indietro erano le parti focalizzate del sistema operativo user -. Ciò significa che /usr potrebbe trovarsi su un volume fisico diverso, il che era una cosa positiva ai tempi di 92 MB di unità disco rigido delle dimensioni delle lavatrici .

I primi sistemi Unix sono stati attenti a mantenere i file del sistema operativo principale fuori da /usr in modo da poter ancora avviare in modalità utente singolo² anche se /usr il volume era smontabile per qualche motivo. Il volume di root conteneva strumenti sufficienti per ottenere il /usr volume di nuovo online.

Diversi gusti Unix ora ignorano questo vecchio principio di progettazione poiché anche i piccoli sistemi embedded hanno spazio sufficiente per entrambi i file di volume di root tradizionali e tutto /usr su un singolo volume.³ Collegamento simbolico Red Hat Enterprise Linux, Solaris e Cygwin /bin per /usr/bin e /lib per /usr/lib in modo che non vi sia più alcuna differenza tra queste directory.

.../local/... ovviamente significa computer locale ...

Sì. Si riferisce al fatto che i file in /usr/local dovrebbero essere particolari per quel singolo sistema. I file che sono in qualche modo generici dovrebbero vivere altrove.

Ciò ha anche radici nel modo in cui i sistemi Unix venivano comunemente usati decenni fa, quando tutto ciò era standardizzato. Ancora una volta, i dischi rigidi del tempo erano ingombranti, molto costosi e conservati poco secondo gli standard odierni. Per risparmiare denaro e spazio sui dischi, un laboratorio informatico pieno di scatole Unix condividerebbe spesso la maggior parte di /usr su NFS o qualche altro protocollo di condivisione dei file di rete, quindi ogni box non doveva avere una propria copia ridondante. ⁴ I file specifici di un singolo box andrebbero sotto /usr/local, che sarebbe un volume separato da /usr.

Questo patrimonio storico è il motivo per cui è ancora l'impostazione predefinita per la maggior parte dei software Unix di terze parti da installare in /usr/local installato a mano. La maggior parte di tali software ti consentirà di installare il pacchetto altrove, ma facendo una non scelta, otterrai il default sicuro, che non interferisce con altri percorsi di installazione comuni con scopi più specifici.

Ci sono buoni motivi per fare installare il software altrove. Il team macOS di Apple lo fa quando costruisce, diciamo, bash dal codice sorgente GNU Bash . Usano / come prefisso di installazione, sovrascrivendo /usr/local predefinito, in modo che Bash finisca in /bin.

Un altro esempio è il modo in cui i vecchi sistemi Linux hanno separato il loro software GUI in /usr/X11R6, per tenerlo separato dalla tradizionale riga di comando e curses - software basato. Ciò è stato fatto semplicemente sovrascrivendo il valore predefinito /usr/local prefisso con /usr/X11R6. ⁵

E cos'è/bin?

È l'abbreviazione di "binario", che in questo contesto significa "un file che non è un testo semplice". La maggior parte di questi file sono eseguibili su una scatola Unix, quindi questi due termini sono diventati sinonimi in alcuni ambienti. ("Per favore, costruiscimi un binario per RHEL 7, Fred.")

File di testo su una scatola Unix vivono altrove: /etc, /usr/include, /usr/share, eccetera.

Una volta, anche gli script Shell - che sono semplici file di testo - erano tenuti fuori dalle directory bin, ma anche questa riga è sfocata. Oggi le directory bin in genere contengono qualsiasi tipo di file eseguibile, sia rigorosamente "binario" o meno. ⁶


Note a piè di pagina e digressioni :

  1. La natura primitiva degli strumenti di gestione degli utenti prima di SVR4 significava che HOME=/usr/$NAME schema è stato semplicemente documentato come una convenzione, piuttosto che imposto dagli strumenti software come predefinito.

    Puoi vederlo a pagina 4-8 del " AT&T Unix System V Release 3.2 Manuale dell'amministratore di sistema : qui vedi AT&T che consiglia il vecchio /usr/$NAME schema nell'ultima versione principale di Unix prima che uscisse SVR4.

    Era abbastanza comune nei vecchi sistemi Unix per gli amministratori di sistema scegliere uno schema diverso che avesse più senso per loro. Essere persone, significava inventare molti schemi diversi.

    Uno schema che ho incontrato prima di /home/$NAME è diventato lo standard era /u/$NAME.

    n altro sistema che ho usato nei primi anni '90 aveva così tanti utenti che non potevano adattare tutte le home directory su un singolo volume fisico, quindi hanno usato uno schema come /u1/$NAME, /u2/$NAME e così via, come ricordo. Il disco su cui è finita la tua home directory era semplicemente una questione di cui uno aveva spazio al momento della creazione del tuo account.

  2. Puoi avviare una macOS box in modalità utente singolo tenendo premuto Cmd-S mentre si avvia. Lascia andare una volta che lo schermo diventa nero e viene visualizzato il testo grigio chiaro. È come correre sotto il Terminale, ma occupa l'intero schermo perché la GUI non è ancora iniziata.

    Fai attenzione, stai eseguendo come root.

    Digitare "esci" nella richiesta di root per utente singolo per uscire dalla modalità utente singolo e continuare l'avvio in modalità GUI multiutente.

  3. Sistemi operativi Unixy che ancora appaiono per mantenere i file critici in modalità utente singolo da /usr non può, in effetti, farlo in questi giorni. Una volta ho reso non avviabile una casella di FreeBSD 9 spostando /usr su un volume ZFS. Ho dimenticato che le funzionalità di ZFS-on-root non sono arrivate fino a FreeBSD 10, creando un Catch 22 : il sistema operativo aveva bisogno di file in /usr per montare /usr!

    Questo era abbastanza grave, ma se FreeBSD 9 mantenesse ancora la sua roba di avvio per utente singolo su /usr, Avrei potuto ripararlo sul posto. Dal momento che non si avvia nemmeno in modalità utente singolo con /usr essendo smontabile, chiaramente che la tradizione era stata in qualche modo violata. Ho dovuto fare il boot da un CD di ripristino per riavviare il sistema.

  4. Questo è anche dove otteniamo /usr/share: segrega i file che potrebbero essere condivisi anche tra scatole Unix con diversi tipi di processori. Tipicamente, file di testo: pagine man, dizionario, ecc.

  5. "X11R6" si riferiva alla versione di X Window System alla base delle GUI di Linux al momento in cui questa convenzione era prevalente. I sistemi Linux in genere hanno smesso di segregare il software della GUI nel momento in cui X11R6 è stato sostituito con X.Org .

  6. I sistemi Unix originali hanno mantenuto i loro script Shell principali in /etc per evitare di mescolarli con i veri binari in /bin.

66
Warren Young

/usr/local/bin mostra le radici in stile UNIX dell'ultimo Mac OS (il suo BSD è basato qui sotto).

  • "usr" sta per Risorse di sistema UNIX. Questa è la posizione in cui sono memorizzati i programmi e le librerie di sistema.
  • "local" rappresenta le risorse che non sono state spedite con la distribuzione standard e, di solito, compilate e gestite in base al sito.
  • "bin" rappresenta eseguibili compilati binari.

Questo si è trasformato dalle prime implementazioni di UNIX su Linux e BSD, ma la convenzione è rimasta. Adesso, /usr/bin sarebbe per programmi e librerie "principali" o principali in cui /usr/local/bin sarebbe per i programmi aggiuntivi e le librerie e i programmi non critici.

10
nzwulfin

Consiglierei di fare riferimento a Wikipedia per domande relative alla struttura in generale, tratterà le basi.

Per rispondere direttamente alla tua domanda, tuttavia:

  • / usr è, liberamente, librerie di sistema ed eseguibili non critici
  • / usr/local è, ancora vagamente, per librerie ed eseguibili non di sistema

Questo è il motivo per cui tendi a trovare una struttura simile tra i due;/Usr/{,/local} {bin, sbin, lib}. Essendo nuovo su Shell, quel bit con {} è un'espansione Shell. Prova a eseguire

ls -ld /usr/{,local/}{bin,sbin,lib}

dalla Shell locale per vedere come funziona.

9
Tok

/usr/local/bin è il percorso predefinito più popolare per i file eseguibili, in particolare quelli open source.

Questa è comunque discutibilmente una cattiva scelta poiché, sui sistemi Unix, /usr è stato standardizzato nei primi anni novanta per contenere una gerarchia di file che appartengono al sistema operativo e quindi possono essere condivisi da più sistemi che utilizzano quel sistema operativo.

Poiché questi file sono statici, il /usr Il file system può essere montato in sola lettura. /usr/local sta sconfiggendo questo standard così come è progettato localmente, quindi non condiviso, quindi deve essere letto/scritto per consentire la compilazione locale e non fa parte del sistema operativo. Peccato qualcosa come /opt/local non è stato scelto invece ...

4
jlliagre

Ti consiglio di usare /usr/local per programmi commerciali che potresti installare come Mathematica. Posizionalo nella sua stessa partizione al momento della configurazione. Quando aggiorni il tuo sistema operativo, questa partizione non sarà disturbata e non dovrai reinstallare i suoi contenuti. Quindi usalo per cose che vuoi conservare tra gli aggiornamenti del sistema operativo.

Separatamente, assicurati di dare /home la propria partizione anche per questo motivo.

1
ncmathsadist

Anche questa risposta potrebbe essere utile.

/ Usr/local

L'idea originale dietro /usr/local doveva avere una directory ('local') '/ usr' separata su ogni macchina oltre a /usr, che potrebbe essere montato in sola lettura da qualche altra parte. Copia la struttura di /usr.

Questi giorni, /usr/local è ampiamente considerato come un buon posto in cui conservare programmi autocompilati o di terze parti. Il /usr/local la gerarchia deve essere utilizzata dall'amministratore di sistema durante l'installazione del software in locale. Deve essere sicuro di non essere sovrascritto quando il software di sistema viene aggiornato.

Può essere utilizzato per programmi e dati condivisi tra un gruppo di host, ma non trovati in /usr. Il software installato localmente deve essere inserito in /usr/local piuttosto che /usr a meno che non venga installato per sostituire o aggiornare il software in /usr.

1