Dois-je mettre des extensions de fichier * .sh et * .rb sur tous mes scripts?

J'ai un tas de scripts exécutables roulés à la main dans mon répertoire $ HOME / bin. Certains sont écrits en bash, certains en Ruby. Tous ont la ligne shebang en haut indiquant au shell quel interprète utiliser (bash ou Ruby, dans mon cas).

Je me demande s'il est préférable de mettre des extensions de fichier sur ces scripts pour indiquer dans quel langage de script ils sont écrits? Par exemple, les scripts dans Ruby auraient le suffixe * .rb, et les bash auraient le suffixe * .sh.

Actuellement, ces scripts ont simplement des noms simples sans extension de fichier.

Quelle est la meilleure pratique?

Vous pouvez exécuter des commandes génériques comme ls *.rbou cp *.shsi vous souhaitez organiser vos scripts à l'avenir.

Commencez tôt ou regrettez plus tard, à mon avis.

Les éditeurs comme vimpourront également appliquer la mise en évidence de la syntaxe correcte en fonction du shebang ou de l'extension de fichier.

Cela peut également être accompli en utilisant des modelines dans divers éditeurs. Par exemple pour vim:

# vim: ft=sh

Eh bien - comme la plupart des choses dans la vie: cela dépend de vos besoins.

Vous avez déclaré que ces scripts résident dans un répertoire bin et je suppose que ces scripts doivent être appelés à partir de la ligne de commande. En tant qu'utilisateur, je considère que c'est ennuyeux si je dois taper bla.ksh ou foo.bash. De plus, si le codeur décide de passer à un autre interprète, le nom de la commande changera également et je devrais modifier d'autres scripts qui utilisent ces outils - très ennuyeux, même si l' utilisateur et le codeur sont la même personne.

Mais d'un autre côté, j'utilise des extensions comme .sh ou .tcl dans mes répertoires de construction de projet. De cette façon, je peux utiliser les fonctionnalités make pour déployer les fichiers dans leurs répertoires de destination - mais à ce stade, je supprime le suffixe du fichier.

Il existe évidemment des différences entre les fichiers exécutables dans les binrépertoires et les fichiers "source" modifiables.

• Pour les fichiers source, il est utile d'avoir un suffixe pour voir ce qui est quoi et d'aider certains outils moins intelligents qui ne parviennent pas à analyser la #!ligne.
• Pour les modules, ils ne sont utilisés que par un ensemble de programmes associés, qui utilisent tous le même interprète (ou pas d'interpréteur), et il est classique d'inclure .pm, .shou .sodans de tels cas.
• Pour les programmes exécutables, son nom fait partie du "contrat de programmation" par lequel les utilisateurs et autres scripts l'invoquent. Il est important que le nom ne change pas même si l'implémentation change; donc évidemment le nom de fichier ne doit pas avoir de suffixe

Dans le cas d'un programme compilé, la différence entre "source" et "exécutable" est évidente: l'une contient le code source, l'autre contient le langage machine ou le bytecode interprété. Dans le cas d'un script, il n'y a pas de différence évidente, mais la makecommande maintient une séparation théorique entre le "code source pour un script" et la "version exécutable d'un script": son "compilateur" par défaut pour "script shell" est simplement cp.

Je recommanderais de garder un $HOME/sourcerépertoire séparé , et soit:

• conserver un lien symbolique, tel que créé par ln -s ../source/foo.sh $HOME/bin/foo; ou
• copiez-les manuellement après avoir apporté des modifications (et les avoir testées), en utilisant install -m 755 foo.sh ../bin/foo; ou
• utilisation d'une Makefilerègle pour effectuer une vérification de la syntaxe avant de copier le fichier source de $HOME/sourcedans$HOME/bin

Note de bas de page: un module de script shell n'est utilisable que par un autre script shell et modifie le contexte interne de ce script à l'aide des commandes .ou sourceintégrées. Ceci est différent d'un script exécutable qui (comme tout programme) s'exécute en tant que processus distinct et ne peut pas modifier son processus parent. En règle générale, les modules entrent /usr/lib/name_of_program/name_of_module.shalors que les commandes entrent /usr/bin/name_of_command(sans suffixe).

Ce n'est pas nécessaire. Le noyau est déjà informé du bon interpréteur à utiliser (par la #!ligne), et tous les éditeurs de texte populaires le lisent également, donc ajouter une extension ne ferait rien d'utile, augmenterait seulement la frappe. La seule fois où un programme exécutable a une extension, c'est quand elle est en quelque sorte importante (pour le programme ou l'utilisateur ou les deux).

Les modules et les bibliothèques, en revanche, ont presque toujours des extensions ( .rbpour les modules Ruby, .sopour les bibliothèques partagées ELF, etc.).