it-swarm-fr.com

Qu'est-ce que / usr / local / bin?

Avant aujourd'hui, j'ai utilisé le terminal dans une mesure limitée pour entrer et sortir des répertoires et modifier les dates des fichiers à l'aide de la commande touch. J'avais réalisé toute l'étendue du terminal après avoir installé un script amusant sur Mac et avoir dû chmod 755 le fichier pour le rendre exécutable par la suite.

Je voudrais savoir ce que /usr/local/bin l'est cependant. /usr/, Je suppose, est l'utilisateur de l'ordinateur. Je ne sais pas pourquoi /local/ est là, cependant. Il représente évidemment l'ordinateur local, mais comme il se trouve sur l'ordinateur (ou un serveur), serait-il vraiment nécessaire? Ne serait pas /usr/bin être bien?

Et qu'est-ce que /bin? Pourquoi cette zone est-elle généralement utilisée pour installer des scripts sur le terminal?

93
JFW

/usr/local/bin est destiné aux programmes qu'un utilisateur normal peut exécuter.

  • Le /usr/local la hiérarchie doit être utilisée par l'administrateur système lors de l'installation locale du logiciel.
  • Il doit être protégé contre l'écrasement lors de la mise à jour du logiciel système.
  • Il peut être utilisé pour des programmes et des données qui peuvent être partagés entre un groupe d'hôtes, mais qui ne se trouvent pas dans /usr.
  • Les logiciels installés localement doivent être placés dans /usr/local plutôt que/usr, sauf s'il est installé pour remplacer ou mettre à niveau le logiciel dans /usr.

Cette source permet d'expliquer la norme de hiérarchie du système de fichiers à un niveau plus profond.

Vous trouverez peut-être cet article sur l'utilisation et l'abus de /usr/local/bin intéressant aussi.

82
iamsid

/ usr /, je suppose que c'est l'utilisateur de l'ordinateur.

Proche.

Unix a commencé comme un système d'exploitation multi-utilisateurs, donc ce n'est pas "l'utilisateur", c'est "les utilisateurs", pluriel.

Avant AT&T Unix System V Release 4 (SVR4) est sorti en 1988 avec ses outils de gestion des utilisateurs par défaut pour créer des répertoires personnels des utilisateurs dans /home, l'emplacement conventionnel était /usr. ¹ Votre $HOME le répertoire était peut-être /usr/jfw sur une boîte System III .

/usr contenait également, alors comme maintenant, /usr/bin, /usr/lib, etc. L'expérience a montré que la séparation des répertoires personnels était une bonne pratique de gestion du système, donc avec le /home changement de politique dans SVR4, il a laissé tout ce que nous pensons maintenant comme appartenant à /usr.

/usr avait encore une bonne raison de conserver le nom: ce qui restait, c'était des fichiers qui n'avaient pas besoin d'être disponibles jusqu'à ce que le système soit démarré suffisamment loin pour prendre en charge une utilisation interactive normale. Autrement dit, ce qui restait était les parties focalisées utilisateur - du système d'exploitation. Cela signifiait que /usr pouvait être sur un volume physique différent, ce qui était une bonne chose à l'époque de n disque dur de 92 Mo fait la taille des machines à laver .

Les premiers systèmes Unix ont pris soin de garder les fichiers OS principaux hors de /usr afin que vous puissiez toujours démarrer en mode mono-utilisateur² même si le /usr le volume n'était pas montable pour une raison quelconque. Le volume racine contenait suffisamment d'outils pour obtenir le /usr volume de retour en ligne.

Plusieurs versions Unix ne tiennent plus compte de cet ancien principe de conception, car même les petits systèmes embarqués ont suffisamment de place pour les fichiers de volume racine traditionnels et tous /usr sur un seul volume.³ Red Hat Enterprise Linux, Solaris et Cygwin symlink /bin à /usr/bin et /lib à /usr/lib pour qu'il n'y ait plus de différence entre ces répertoires.

.../local/... signifie évidemment l'ordinateur local ...

Oui. Il fait référence au fait que les fichiers sous /usr/local sont censés être particuliers à ce système unique. Les fichiers qui sont génériques de quelque manière que ce soit devraient vivre ailleurs.

Cela a également ses racines dans la façon dont les systèmes Unix étaient couramment utilisés il y a des décennies lorsque tout cela a été normalisé. Encore une fois, les disques durs de l'époque étaient encombrants, vraiment chers et peu stockés par rapport aux normes actuelles. Pour économiser de l'argent et de l'espace sur les disques, un laboratoire informatique rempli de boîtes Unix partagerait souvent la plupart des /usr sur NFS ou un autre protocole de partage de fichiers réseau, de sorte que chaque boîte n'a pas besoin d'avoir sa propre copie redondante. Les fichiers spécifiques à une seule boîte iraient sous /usr/local, qui serait un volume distinct de /usr.

Cet héritage historique explique pourquoi c'est toujours la valeur par défaut pour la plupart des logiciels Unix tiers à installer dans /usr/local lorsqu'il est installé à la main. La plupart de ces logiciels vous permettent d'installer le package ailleurs, mais en faisant un non-choix, vous obtenez la valeur par défaut sûre, qui n'interfère pas avec d'autres emplacements d'installation courants à des fins plus spécifiques.

Il y a de bonnes raisons de faire installer le logiciel ailleurs. L'équipe macOS d'Apple le fait quand elle construit, disons, bash à partir du code source GNU Bash . Ils utilisent / comme préfixe d'installation, remplaçant /usr/local par défaut, pour que Bash se retrouve dans /bin.

Un autre exemple est la façon dont les anciens systèmes Linux ont séparé leur logiciel GUI en /usr/X11R6, pour le séparer de la ligne de commande traditionnelle et des logiciels basés sur curses . Cela a été fait simplement en remplaçant la valeur par défaut /usr/local préfixe avec /usr/X11R6. ⁵

Et qu'est-ce que/bin?

C'est l'abréviation de "binaire", qui dans ce contexte signifie "un fichier qui n'est pas du texte brut". La plupart de ces fichiers sont exécutables sur une boîte Unix, donc ces deux termes sont devenus synonymes dans certains cercles. ("Veuillez me construire un binaire pour RHEL 7, Fred.")

Les fichiers texte sur une boîte Unix vivent ailleurs: /etc, /usr/include, /usr/share, etc.

Il était une fois, même les scripts Shell - qui sont des fichiers de texte brut - étaient conservés hors des répertoires bin, mais cette ligne aussi est floue. Aujourd'hui, les répertoires bin contiennent généralement tout type de fichier exécutable, qu'il soit strictement "binaire" ou non.


Notes et digressions :

  1. La nature primitive des outils de gestion des utilisateurs avant SVR4 signifiait que le HOME=/usr/$NAME Le schéma était simplement documenté comme une convention, plutôt qu'appliqué par défaut par les outils logiciels.

    Vous pouvez le voir à la page 4-8 du " Guide de l'administrateur système AT&T Unix System V version 3.2 : ici vous voyez AT&T recommander l'ancien /usr/$NAME schéma dans la dernière version majeure d'Unix avant la sortie de SVR4.

    Il était assez courant dans les anciens systèmes Unix que les administrateurs système choisissent un schéma différent qui leur paraissait plus logique. Les gens étant des gens, cela signifiait que de nombreux régimes différents ont été inventés.

    Un schéma que j'ai rencontré avant /home/$NAME est devenu la norme était /u/$NAME.

    n autre système que j'ai utilisé au début des années 1990, il y avait tellement d'utilisateurs qu'ils ne pouvaient pas ranger tous les répertoires personnels sur un seul volume physique, ils ont donc utilisé un schéma comme /u1/$NAME, /u2/$NAME, et ainsi de suite, si je me souviens bien. Le disque sur lequel votre répertoire personnel s'est retrouvé était simplement une question de savoir lequel avait de l'espace au moment de la création de votre compte.

  2. Vous pouvez démarrer une boîte macOS en mode mono-utilisateur en maintenant enfoncée Cmd-S pendant qu'il démarre. Lâchez prise lorsque l'écran devient noir et que du texte gris clair apparaît. C'est comme courir sous le Terminal, mais il occupe tout l'écran car l'interface graphique n'a pas encore commencé.

    Attention, vous exécutez en tant que root.

    Tapez "exit" à l'invite racine mono-utilisateur pour quitter le mode mono-utilisateur et continuer le démarrage en mode GUI multi-utilisateur.

  3. OS Unixy qui - apparaissent pour garder les fichiers critiques en mode mono-utilisateur hors de /usr peut ne pas le faire de nos jours. Une fois, j'ai rendu une boîte FreeBSD 9 non amorçable en déplaçant /usr vers un volume ZFS. J'ai oublié que les fonctionnalités ZFS sur root n'ont pas atterri avant FreeBSD 10, créant un Catch 22 : le système d'exploitation avait besoin des fichiers dans /usr pour monter /usr!

    C'était déjà assez grave, mais si FreeBSD 9 gardait toujours ses trucs de démarrage pour utilisateur unique hors de /usr, J'aurais pu le fixer en place. Puisqu'il ne démarrerait même pas en mode mono-utilisateur avec /usr étant indémontable, il est clair que la tradition avait été violée d'une manière ou d'une autre. J'ai dû démarrer à partir d'un CD de secours pour récupérer ce système.

  4. C'est aussi là que nous obtenons /usr/share: il sépare les fichiers qui pourraient être partagés même entre des box Unix avec différents types de processeurs. Généralement, les fichiers texte: pages de manuel, dictionnaire, etc.

  5. "X11R6" fait référence à la version des X Window System qui sous-tendent les interfaces graphiques Linux au moment où cette convention était répandue. Les systèmes Linux ont généralement cessé de séparer le logiciel GUI au moment où X11R6 a été remplacé par X.Org .

  6. Les systèmes Unix d'origine ont conservé leurs principaux scripts Shell dans /etc afin d'éviter de les mélanger avec les vrais binaires dans /bin.

66
Warren Young

/usr/local/bin montre les racines UNIX-esque du dernier Mac OS (son BSD basé en dessous).

  • "usr" signifie UNIX System Resources. Il s'agit de l'emplacement de stockage des programmes système et des bibliothèques.
  • "local" représente les ressources qui n'ont pas été livrées avec la distribution standard et, généralement, compilées et gérées par site.
  • "bin" représente les exécutables compilés binaires.

Cela s'est transformé depuis les premières implémentations d'UNIX sur Linux et BSD, mais la convention est restée. Maintenant, /usr/bin serait pour les programmes et bibliothèques "principaux" ou principaux où /usr/local/bin serait destiné aux programmes et bibliothèques complémentaires et non critiques.

10
nzwulfin

Je recommanderais de faire référence à Wikipedia pour les questions liées à la structure en général, il couvrira les bases.

Pour répondre directement à votre question, cependant:

  • / usr est, en gros, des bibliothèques système et des exécutables non critiques
  • / usr/local est, encore une fois vaguement, pour les bibliothèques non exécutables et les exécutables

C'est pourquoi vous avez tendance à trouver une structure similaire entre les deux;/usr/{, local /} {bin, sbin, lib}. Étant nouveau dans le shell, ce bit avec le {} est une extension du shell. Essayez d'exécuter

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

de votre Shell local pour voir comment cela fonctionne.

9
Tok

/usr/local/bin est l'emplacement par défaut le plus populaire pour les fichiers exécutables, en particulier ceux open source.

Ceci est cependant sans doute un mauvais choix car, sur les systèmes Unix, /usr a été normalisé au début des années 90 pour contenir une hiérarchie de fichiers qui appartiennent au système d'exploitation et peuvent donc être partagés par plusieurs systèmes utilisant ce système d'exploitation.

Comme ces fichiers sont statiques, le /usr le système de fichiers peut être monté en lecture seule. /usr/local va à l'encontre de cette norme car il est par conception local donc non partagé, il doit donc être en lecture-écriture pour permettre la compilation locale et ne fait pas partie du système d'exploitation. Dommage quelque chose comme /opt/local n'a pas été choisi à la place ...

4
jlliagre

Je vous recommande d'utiliser /usr/local pour les programmes commerciaux que vous pourriez installer tels que Mathematica. Placez-le dans sa propre partition lors de la configuration. Lorsque vous mettez à niveau votre système d'exploitation, cette partition ne sera pas perturbée et vous n'aurez pas à réinstaller son contenu. Utilisez-le donc pour tout ce que vous souhaitez conserver entre les mises à niveau du système d'exploitation.

Séparément, assurez-vous de donner /home sa propre partition pour cette raison aussi.

1
ncmathsadist

Cette réponse pourrait également être utile.

/ usr/local

L'idée originale derrière /usr/local devait avoir un répertoire séparé ('local') '/ usr' sur chaque machine en plus de /usr, qui pourrait être monté en lecture seule ailleurs. Il copie la structure de /usr.

Ces jours-ci, /usr/local est largement considéré comme un bon endroit pour conserver des programmes auto-compilés ou tiers. Le /usr/local la hiérarchie doit être utilisée par l'administrateur système lors de l'installation locale du logiciel. Il doit être protégé contre l'écrasement lors de la mise à jour du logiciel système.

Il peut être utilisé pour des programmes et des données partagés entre un groupe d'hôtes, mais introuvables dans /usr. Les logiciels installés localement doivent être placés dans /usr/local plutôt que /usr sauf s'il est installé pour remplacer ou mettre à niveau le logiciel dans /usr.

1
Vishwanath gowda k