2 votes

Meilleure pratique pour l'emplacement du shell de l'utilisateur scripts et/ou PATH

J'aimerais savoir s'il existe un meilleure pratique pour placer/stocker les scripts personnalisés de l'interpréteur de commandes (Bash/Zsh) et l'emplacement PATH correspondant.

Je sais que les gens ont leurs endroits préférés - j'ai l'habitude de jeter les miens dans /opt/local/bin mais cela nécessite des autorisations Root ( sudo ) et il était "mélangé" avec toutes les affaires de MacPorts ; il était donc pour le moins désorganisé. Donc, ce n'est pas ce que je recherche - une opinion sur ce que chaque individu a préféré.

Existe-t-il une recommandation généralement acceptée d'un emplacement/méthodologie pour stocker les scripts personnalisés à la fois sur l'ensemble du système (tous les utilisateurs) pour les scripts personnels des utilisateurs individuels (peut-être dans leur répertoire personnel ?) et si nécessaire (et disponible), comment structurer le PATH ?

0 votes

Cela vous dérange si nous fermons ceci comme un doublon de apple.stackexchange.com/questions/98619/ ?

0 votes

@nohillside votre réponse a besoin de zsh ajouté pour répondre à cela et aussi voir mon nouveau commentaire

0 votes

Je n'utilise pas zsh moi-même, mais cela ne me dérangerait pas que quelqu'un de plus compétent que moi modifie cette réponse (ou en ajoute une nouvelle).

4voto

Oskar Points 1242

Mettez les choses en place /usr/local est la meilleure pratique pour une utilisation globale

Le fait que votre utilisateur individuel ait besoin d'une aire de jeu / d'un chemin / d'un espace séparé est plus délicat à résoudre.

  • Combien d'utilisateurs ?
  • D'où viennent-ils en termes d'accès / d'authentification ?

Les meilleures pratiques (c'est-à-dire celles qui sont réalisables et optimales) ne sont pas les mêmes pour trois personnes qui se connectent par ssh à une machine ou pour des milliers d'étudiants et de professeurs qui utilisent une architecture mature de partage de fichiers et de dossiers personnels sur le réseau, ou encore pour les développeurs qui enregistrent leur code dans le contrôle de la source, accèdent à de nombreuses machines et souhaitent synchroniser leurs données.

Il n'y a probablement pas de meilleure pratique que de connaître vos utilisateurs, leur niveau de compétence et leurs outils préférés et de travailler avec votre budget d'assistance. Les outils qu'une équipe informatique professionnelle ou une équipe de développement conçoit, fournit et prend en charge seront bien plus puissants que ceux d'un couple de personnes partageant un Mac mini au bureau. Ces mêmes outils sont excessifs pour un petit groupe ou une personne qui configure plusieurs comptes.

En fonction de votre volume d'éléments, des sous-répertoires dans le dossier utilisateur local peuvent être très utiles. La seule autre suggestion que j'ai vue et qui vaut la peine d'être prise en compte est la suivante /Library ou ~/Library mais ils sont plus éloignés de l'héritage unix/shell à mon goût.

2 votes

Quels que soient les enjeux de cette question, je peux confirmer que j'ai cherché une réponse similaire au fil des ans, et que je n'ai rien trouvé qui puisse être considéré comme un consensus sur le fait qu'il soit meilleur que /usr/local/. Même là, vous pouvez trouver des gens qui ne sont pas d'accord, mais ce n'est pas parce qu'ils ont une meilleure idée, c'est parce qu'ils n'aiment pas celle-ci. Personnellement, je suis allé avec /usr/local/scripts/ juste pour pouvoir séparer mes éléments de Homebrew, etc, mais ce n'est pas un consensus, juste la pratique d'une personne.

1 votes

@TJLuoma brew fait quelque chose de similaire : mettre les alias dans /usr/local mais garder les scripts dans Cellar . Cela semble être un moyen propre et non destructif de faire les installations/désinstallations.

0 votes

@ankii Ouaip, et je comprends ce modèle, mais j'ai trouvé plus facile de mettre /usr/local/scripts/ dans mes $PATH .

LesApples.com

LesApples est une communauté de Apple où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres utilisateurs d'appareils Apple, poser vos propres questions ou résoudre celles des autres.

Powered by:

X