Où est le bon endroit permanent pour installer des scripts bash personnalisés?

32

Je suis sur le point d'installer "leiningen" qui est un script bash pour le langage de programmation clojure avec beaucoup d'utilité ... ... mais je ne suis pas sûr de savoir où il est approprié de -put- un script exécutable sous Linux système de sorte qu’il soit disponible de manière permanente et stable.

Je ne pense pas que n'importe où dans / home ait du sens, mais je ne sais pas quel répertoire / quels répertoires sont supposés être utilisés pour cela.

/ usr / share?

— Kzqai
source

1

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

— Ignacio Vazquez-Abrams

45

(Note: ~traduit comme /home/userdans ce post)

Personnellement, je mets tous mes scripts système personnalisés /usr/local/binet tous mes scripts bash personnels dans ~/bin. Très peu de programmes que j'installe se placent dans des /usr/local/binrépertoires, de sorte qu'ils ne sont pas très encombrés et que cela se trouvait déjà dans la $PATHvariable de la plupart de mes machines.

Pour ajouter /usr/local/binà votre chemin système (s'il n'y est pas déjà), ajoutez ceci à /etc/profile:

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

Pour ajouter ~/binau chemin de votre utilisateur, ajoutez ceci à ~/.bash_profile:

PATH=$PATH:$HOME/bin
export PATH

Parfois , le défaut .bash_profilefichier aura une instruction if qui ajoute automatiquement ~/binà $PATHsi elle existe, donc créer ~/binet ouvrir un nouveau terminal pour voir si le vôtre fait déjà.

— Trey Hunner
source

Les BSD le font par défaut.

— Chris S

@Chris: Les BSD ont mis beaucoup de choses dans / usr / local / bin

— Dan Andreatta

Quelle est la différence entre vos scripts bash et vos scripts système, et y a-t-il une raison pour laquelle vous séparez les deux?

— Hashim

@Hashim Je ne peux évidemment pas parler pour Trey, mais les outils que vous développez pour vos besoins personnels ont tendance à "passer" aux outils système lorsque vous remarquez qu'ils résolvent un problème avec lequel les autres ont des problèmes, ou que vous avez une autre installation à l'échelle du système qui dépend sur l'un de ces outils. Je soupçonne que le seuil requis pour installer quelque chose à l'échelle du système est plutôt élevé pour la plupart des programmeurs. De plus, un outil que vous partagez doit avoir une documentation, que de nombreux développeurs écrivent rarement autrement.

— tripleee

Soit dit en passant, il n'est pas nécessaire de exportdéfinir plusieurs fois une variable (et probablement votre système est déjà marqué PATHpour l'exportation, vous n'avez donc pas à le faire vous-même).

— tripleee

9

/ usr / local / est vraiment le bon endroit, alors que / opt est vraiment destiné aux applications tierces; "/ opt est réservé à l'installation de packages logiciels d'application supplémentaires." Cela fait partie de la norme de hiérarchie du système de fichiers.

Voir http://www.pathname.com/fhs/pub/fhs-2.3.html pour une discussion sur / opt.

Pour / usr / local /, c'est pour "utilisation par l'administrateur système". N'oubliez pas tout ce qu'il y a dedans - documentez-le.

— Jamieson Becker
source

Le lien que vous avez fourni indique "Les répertoires / opt / bin, / opt / doc, / opt / include, / opt / info, / opt / lib et / opt / man sont réservés à l’utilisation des administrateurs système locaux". Il n'y a rien dans / usr / local. Seul / usr / local / share y est mentionné. En revanche, les programmes compilés sont généralement installés dans / usr / local sous Linux. Ne pensez-vous pas que / opt / bin est le meilleur endroit pour être utilisé par l'administrateur système?

— raacer

1

Mon expérience est que /usr/local, comme son nom l’indique, correspond à l’administrateur local et /optaux éléments qui ne sont pas distribués officiellement, tels que les logiciels tiers commerciaux gérés par un processus similaire (pouvant être remplacés ou effacés lors d’une mise à niveau). en amont) mais non gérée par le gestionnaire de paquets de la distribution, ou peut-être réellement distribuée sous forme de RPM ou de .debpaquets, mais non organisée et empaquetée conformément à toutes les politiques et conventions de la distribution.

— tripleee

1

@raacer Il y a une section séparée entièrement à propos de /usr/localplus tard dans le document.

— tripleee

@raacer tripleee a raison. Voici le lien: pathname.com/fhs/pub/… .. programmes corrects et compilés (généralement open source) compilés / construits spécifiquement pour ce système ou partagés entre plusieurs systèmes (mais ne faisant pas partie de la structure / distribution normale du système d'exploitation, mais qui reposent beaucoup sur les bibliothèques partagées) doivent être installés dans / usr / local (reflète fondamentalement la hiérarchie de / usr). Les logiciels tiers compilés sur un système éventuellement différent avec éventuellement leur propre support de bibliothèque (par exemple, firefox, userify) doivent aller dans / opt.

— Jamieson Becker le

3

Historiquement, vous utiliseriez quelque chose comme / opt. Tout va bien tant qu'il est mis à jour dans $ PATH pour les utilisateurs supposés l'avoir (par conséquent, tout ce qui est dans / home est une mauvaise idée).

— Tony
source

2

/usr/share/clojuresemble être un lieu commun pour placer les fichiers binaires et les bibliothèques de clojure (pourquoi je ne sais pas, cela semble naturel pour) /usr/local/share/clojure, aussi la création d’un sitesous - répertoire sous ce répertoire pour ces scripts bash semble bien aller.

L'idée générale est qu'il est plus logique d'organiser les scripts par fonction sans avoir tous les scripts bash au même endroit.

— Charles Stewart
source

1

Il y a quelques problèmes d'utilisation /usr/sharepour cela. Tout d'abord, il sharefaut entendre les fichiers indépendants de l'architecture (c'est-à-dire partagés entre les architectures). Pour cette raison, les bibliothèques et les exécutables n'appartiennent pas à un sharerépertoire. Deuxièmement, à part /usr/localrien d'autre que le gestionnaire de paquet de distribution devrait écrire dans /usr.

— Kasperd

2

/usr/local, Je pense qu’il ya une certaine confusion dans la signification de "local".

Si je comprends bien, "local" ne signifie pas "en provenance de / sur la machine locale" mais, plus simplement, "spécifique à la machine locale", pouvant ou non provenir de la machine locale.

— Hatebit
source