Extensions de fichier pour les scripts de shell unix [fermé]


45

Sur Wikipédia, l'article pour .sh dit:

Pour le type d'extension de fichier .sh, voir Bourne shell .

Qu'en est-il des autres coques Unix?

Je sais que le shebang est utilisé à l'intérieur du fichier pour indiquer un interprète à exécuter, mais je me demande:

  • Quels sont les avantages et les inconvénients des extensions de fichier par rapport à aucune extension de fichier?

4
Parfois, des scripts de shell sans shebang (ou sans autorisations d’exécution) peuvent être trouvés. Dans ce cas, un nom se terminant par .sh peut être un indice pour l'utilisateur de les exécuter avec bash script.sh(ou shbien sûr).
Ansgar Esztermann

3
Si un script shell a une extension, il s'agit généralement de .sh. Je n'ai jamais vu un script .ksh ou .bash. La plupart des scripts de shell n'ont cependant pas d'extension, comme tous les scripts de /etc/init.d/* par exemple.
Richard Holloway

Bien qu'une conclusion simpliste (oui ou non) soit une opinion, les éléments à prendre en compte ne le sont pas.
ctrl-alt-delor

Réponses:


35

Je voudrais seulement appeler .shquelque chose qui est censé être portable (et espérons-le est portable).

Sinon, je pense que c'est mieux de cacher la langue. Le lecteur attentif le trouvera de toute façon dans la ligne shebang. (En pratique, .bashou .zsh, etc…, les suffixes sont rarement utilisés.)


1
À partir de cette seule page, nous pouvons déjà voir un nombre non négligeable de personnes l’utilisant. Pourquoi dites-vous qu'ils sont "rarement utilisés"? Des citations? Ou est-ce simplement basé sur votre expérience?
Pacerier

23

Je dirais qu’il n’existe pas de "bonnes pratiques" pour les extensions de fichiers, pour des raisons techniques: les systèmes de fichiers Unix / Linux / * BSD ne prennent pas en charge les extensions en tant que telles. Ce que vous appelez une extension est simplement un suffixe d'un nom de fichier unique. Cela diffère des systèmes de fichiers et systèmes d'exploitation VM / CMS, VMS, MS-DOS et Windows pour lesquels un emplacement spécial dans l'équivalent moral d'inode est réservé pour une extension.

Ce petit délire maintenant, je pense que c'est un peu idiot de mettre un suffixe ".sh" ou ".ksh" ou ".bash" sur un nom de fichier de script shell. Un programme est un programme: il n’ya aucun avantage à distinguer ce qui est exécuté. Aucun unix, ni linux, ni aucun autre noyau n’a décidé d’appeler un interpréteur sur un fichier uniquement à cause du suffixe du nom de fichier. Tout se fait par la #!ligne ou par une autre séquence d'octets "nombre magique" au début du fichier. En fait, décider de ce qu'il faut exécuter en fonction du nom de fichier "extension" est l'un des facteurs qui font de Windows un pôle d'attraction des programmes malveillants. Regardez combien d'escroqueries par des programmes malveillants Windows impliquent un fichier nommé "quelquechose.jpg.exe" - par défaut, les nouvelles versions de Windows n'indiquent pas l'extension ".exe" et encouragent l'utilisateur à double-cliquer sur le "

Ce que vous pouvez penser comme une commande directe est souvent un script shell. Parfois, cca été un script sh, firefoxest un script sh, startxest un script sh. Je ne crois pas qu'il y ait un avantage cognitif ou organisationnel à marquer un script avec un suffixe ".sh".


24
Je ne suis pas d'accord! Mon travail consiste à empaqueter une application impliquant des milliers de fichiers allant d'exécutables binaires à des scripts de shell (ksh, bash et certains csh hérités). Pour moi, croyez-moi, le fait de savoir en un coup d'œil (ou dans une regex) quel type de fichier que nous discutons et que nous recherchons fait une différence. Ce que je veux dire, c'est qu'il pourrait être avantageux de distinguer ce qui est excuté. Une meilleure pratique devrait encourager à indiquer explicitement le type de fichier.
Rahmu

4
@rahmu: écrivez cela comme une réponse. Donnez des détails sur la façon dont les noms distinguables par une expression rationnelle vous aident à empaqueter (et peut-être à maintenir) cette application. Notez spécifiquement l'interaction entre ce qui interprète le fichier et le suffixe du nom de fichier et comment cela vous aide dans l'exécution des tâches. Je suis intéressé par des arguments sérieux contre mon point de vue, et je suis prêt à changer si je suis convaincu. J'ai voté votre commentaire pour le prouver.
Bruce Ediger

3
J'aimerais beaucoup, malheureusement, je ne peux parler que de mon expérience actuelle dans mon travail actuel. Je ne connais pas grand chose aux bonnes pratiques et aux normes en général ; Je pense que je devrais faire des recherches avant de poster une réponse ici.
J'examinerai la question

2
@rahmu La commande "file" existe pour déterminer le type de fichier. Il est capable de distinguer les scripts écrits pour différents shells.
Matt

3
Si vous attribuez une .shextension à un script shell , vous devrez la saisir .shdans le nom de la commande lors de son démarrage. C'est la raison principale pour laquelle je n'aime pas mettre cette extension dans (même chose avec une ligne de shebang). BTW, le problème dans Windows n’est pas le .exepréfixe en soi (c’est simple de créer un exécutable nommé image.jpgsous Linux, après tout), mais le fait que Windows cache généralement cette extension, combiné au fait que l’action nécessaire pour démarrer un exécutable et ouvrir un document est exactement la même chose.
celtschk

12

En tant que personne ayant travaillé dans une multitude d’environnements? Nix, j’ai dû écrire dans une grande variété de coques. Croyez-le ou non, sur les plateformes, les coquilles ne sont pas les mêmes. Donc, si vous maintenez votre bibliothèque personnelle dans plusieurs shells (si nécessaire), il est très utile d'utiliser des extensions pour identifier les shells. Ainsi, lorsque vous passez à une autre plate-forme et que le shell est légèrement différent, vous savez quels scripts cibler pour les modifications. .sh .ksh .bsh .csh ...


Cela semble être en accord avec unix.stackexchange.com/questions/31760/…
Pacerier

Avez-vous pas un #!au début du script (par exemple #!/bin/bash)?
ctrl-alt-delor

Gnu / Linux, BSD et les UNIX sont tous Unix. Pas besoin de? Nix. Linux est un noyau, Android utilisait Linux mais n'était pas Unix (sauf si vous ajoutez un logiciel supplémentaire, auquel cas vous avez une application Unix).
ctrl-alt-delor

@ ctrl-alt-delor: "Unix" est une marque . Les gens utilisent souvent "? Nix" pour éviter le problème de la marque (et des pédants).
JS.

@JS «UNIX» est une marque commerciale de The Open Group. Unix et unix ne sont pas greens.org/about/unix.html
ctrl-alt-delor

6

Vous ne devez pas utiliser d’extension pour les exécutables, car ils ne sont pas interchangeables. Imaginez que vous ayez un script shell a.sh, puis réécrivez en python a.py. Vous devez maintenant changer tous les programmes qui vous appellent script, vous avez perdu le détail de l’implémentation.

L'extension complète du nom de fichier dans Windows de Mircosoft est un désordre: par exemple, ce qui aurait pu être a.audio, b.audio, c.audio, est a.mp3, b.wav, c.ogget d.picture, e.picture, f.pictureest d.jpeg, e.png, f.gif. La plupart du temps, peu importe le format de l'audio ou de l'image. Nous devons également passer beaucoup de temps à enseigner aux nouveaux utilisateurs toutes les extensions de fichiers.


Une autre raison de ne pas utiliser que *.shje viens de rencontrer est que Debian n’exécutera run-partspas de scripts avec des extensions, comme dans /etc/cron.*/: archive.oreilly.com/pub/post/runparts_scripts_a_note_about.html
Ross Patterson

5

Comme vous l'avez dit, les extensions de fichier Unix sont purement informatives. Vous avez juste besoin de votre script pour avoir un shebang correct et être exécutable.

Vous pouvez soit ne pas avoir d'extension ou utiliser .sh.

J'utilise personnellement les conventions suivantes, quel que soit le shell utilisé (csh, tcsh, bash, sh, ...):

  • pas d'extension pour les scripts système ou de haut niveau (extrêmement rare).
  • le .shpour les scripts classiques, bas à haut grade.

Qu'entendez-vous par "scripts classiques, de bas en haut"?
Pacerier

Je pense que je voulais dire abstraction ou niveau d'organisation par cela. C'est-à-dire que vous ne vous souciez pas de la langue / de l'outil de script utilisé derrière certaines commandes: vous n'utilisez donc aucune extension. Pour d'autres, il est bon de savoir qu'il s'agit d'un script shell ksh exotique (avec l'extension appropriée). ... mais c'était il y a 2 ans;)
Ouki

3

Les extensions de script shell sont très utiles. Par exemple, j'écris souvent des scripts contenant plusieurs fichiers dans plusieurs langues (par exemple, bash, awk et lua) dans le même répertoire. Si j'ai besoin de rechercher une chaîne uniquement dans les fichiers bash, l'extension le rend très pratique pour réduire les faux positifs. Ou si je veux faire un compte ligne de tout mon code bash pour ce projet.

Il est difficile de taper l'extension lors de l'exécution du programme. Je crée donc également un lien symbolique sans l'extension vers l'exécutable principal, pour le modifier / l'exécuter sans avoir à taper l'extension à chaque fois. Les liens symboliques sont économiques et faciles.


Cela semble être en accord avec unix.stackexchange.com/questions/31760/…
Pacerier

2

Comme d'autres l'ont dit, le shell ne se soucie pas des extensions. Cependant, cela permet une identification humaine rapide des fichiers. Je vois des fichiers se terminant par .pyou .shet je sais rapidement ce qu'ils devraient (au moins). Comme le dit Steve, la recherche par extension de fichier ou le comptage de lignes sont également des considérations pratiques.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.