Qu'est-ce que le Bash extension de fichier?

J'ai écrit un script bash dans un éditeur de texte, quelle extension dois-je enregistrer mon script de sorte qu'il peut fonctionner comme un script bash? J'ai créé un script qui devrait en théorie démarrer un serveur ssh. Je me demande comment le script de s'exécuter une fois que je clique sur elle. Je suis sous OS X 10.9.5.

  • Shell script ne nécessite pas d'extension particulière. Juste l'exécuter comme bash myscript
  • Généralement .sh, mais l'extension n'est pas nécessaire à l'existence à tous. Linux n'est pas Windows. Le programme qui doit interpréter votre script est déterminé dans sa première ligne, qui devrait être #!/bin/bash. Il peut même inclure des paramètres.
  • Comment aurais-je obtenir mon script à exécuter si j'étais juste à double cliquer dessus et pas vraiment de type "bash myscript"
  • que serait-tête de votre fichier avec la ligne #!/bin/bash.
  • Vous devriez expliquer ce qu'est votre script en train de faire (ou peut-être même de le montrer dans votre question) et sur quel système d'exploitation et l'environnement de bureau. Donc merci d'éditer votre question à l'améliorer.
  • Vérifier mon édité question
  • Vérifier mon édité réponse. Je suppose qu'en faisant de votre script exécutable de votre bureau pourrait montrer cliquable application, mais je n'en suis pas sûr.
  • Pas d'extensions: Commandname extensions considérées comme nuisibles.
  • La question est vraiment à avoir bash script exécuté dans macos, mais il n'y a aucune indication à ce sujet dans le titre ou les étiquettes?!

InformationsquelleAutor Amedeo | 2015-01-07
  1. 78

    Pas d'accord avec les autres réponses, il y a une convention commune à l'utilisation d'un .sh extension pour les scripts shell, -- mais ce n'est pas une convention utile. Il est préférable de ne pas utiliser une extension à tous. L'avantage de pouvoir dire que foo.sh est un script shell en raison de son nom est minime, et vous payez pour cela avec une perte de flexibilité.

    De faire un script bash fichier exécutable, il doit avoir un shebang ligne en haut:

    #!/bin/bash

    et l'utilisation de la chmod +x commande de manière à ce que le système reconnaît comme un fichier exécutable. Ensuite, il doit être installé dans l'un des répertoires listés dans votre $PATH. Si le script est appelé foo, vous pouvez l'exécuter à partir d'une invite du shell en tapant foo. Ou si c'est dans le répertoire courant (courant pour temporaire de scripts), vous pouvez taper ./foo.

    Ni le shell ni le système d'exploitation paie toute l'attention à l'extension de la partie du nom de fichier. C'est juste une partie du nom. Et par pas lui donnant une extension, vous vous assurez que quelqu'un (un utilisateur ou d'un autre script) qui l'utilise n'avez pas à vous souciez de la façon dont il a été mis en œuvre, si c'est un script shell (sh, bash, csh, ou quoi que ce soit), Perl, Python, ou script Awk, ou un binaire exécutable. Le système est spécialement conçu pour que soit interprété script ou un fichier binaire exécutable peut être invoquée sans savoir ou comment prendre soin de sa mise en œuvre.

    Les systèmes de type UNIX a commencé avec un purement textuel de l'interface de ligne de commande. Les interfaces graphiques comme KDE et Gnome ont été ajoutés plus tard. Dans une interface graphique, système de bureau, vous pouvez généralement exécuter un programme (encore une fois, si c'est un script ou un fichier binaire exécutable), par exemple, en double-cliquant sur une icône qui s'y rapporte. Typiquement, cela élimine toute sortie du programme d'impression et ne pas vous laisser passer des arguments de ligne de commande; il est beaucoup moins souple que de courir à partir de l'invite du shell. Mais pour certains programmes (principalement des clients GUI), il peut être plus pratique.

    Script Shell qui est le mieux appris à partir de la ligne de commande, et non pas à partir d'une interface graphique.

    (Certains outils ne payer l'attention sur les extensions de fichier. Par exemple, les compilateurs utilisent généralement l'extension de déterminer la langue, le code est écrit en: .c pour C, .cpp pour le c++, etc. La présente convention ne s'applique pas à des fichiers exécutables.)

    Gardez à l'esprit que UNIX et UNIX-like) pour les systèmes non-Windows. MS Windows utilise généralement une extension de fichier pour déterminer comment ouvrir/exécuter. Exécutables binaires besoin d'avoir un .exe extension. Si vous avez un type UNIX, shell installé sous Windows, vous pouvez configurer Windows pour reconnaître un .sh extension comme un script shell, et utiliser le shell pour l'ouvrir; Windows n'a pas le #! convention.

    • Ce que je vise est ce que vous avez mentionné au quatrième alinéa. L'exécution de mon script lors d'un clic sur une icône qui s'y rapporte.
    • Ensuite, cela dépend de votre environnement de bureau. Dans celui que j'utilise (Cannelle sous Ubuntu), en double-cliquant sur l'icône d'un script exécutable me demande de l'exécuter dans un terminal, de les afficher dans un éditeur de texte, ou de l'exécuter sans un terminal. Elle fait ce quelle que soit l'extension de fichier.
    • (Necro) Si vous omettez l'extension, vous ne pouvez pas avoir le même nom de dossier. Ainsi, par exemple, vous avez deploy.sh (ou deploy.bash), et un dossier, deploy, avec le déploiement de la logique. Si vous renommez le script pour simplement deploy il va provoquer un conflit de nom. Nommage de fichier ou de dossier différemment mal de facilité de gestion et, éventuellement, le fichier de tri (ls, éditeurs, etc.). Bien sûr, l'arborescence n'est en fin de compte le facteur déterminant. Mais des extensions de fichier n'ont droit à leur place.
    • Je ne pense pas que j'ai jamais ressenti le besoin d'avoir un script et un répertoire avec le même nom. Si je le faisais, que je pourrais appeler le répertoire Deploy, mais qui peut causer des problèmes lors de la copie à la casse du système de fichiers.
    • Sur un Mac, double-cliquez sur les fichiers toujours s'ouvre dans l'application par défaut. Ainsi, il est utile d'avoir un .sh extension afin que le script s'ouvre dans votre choix de l'éditeur. Si vous souhaitez exécuter un script lors d'un double clic, donnez-lui le .command extension et il va s'exécuter dans le Terminal lors d'un double clic.
    • De nombreuses applications 3ème partie s'appuient sur l'extension. L'éditeur de mise en forme est prédominante.
    • Peut-être, mais au moins emacs et vim sont en mesure de reconnaître un script bash sans l'extension de fichier. Je ne suis pas sûr qu'ils regardent la #!/bin/bash de la ligne ou de la syntaxe du fichier.

    InformationsquelleAutor Keith Thompson
  2. 15

    Vous n'avez pas besoin d'extension (ou vous pouvez choisir arbitraire, mais .sh est une convention utile).

    Vous devriez commencer votre script avec #!/bin/bash (que la première ligne est entendu par execve(2) syscall), et vous devriez faire de votre fichier exécutable par chmod u+x. donc, si votre script est un fichier $HOME/somedir/somescriptname.sh vous avez besoin de taper une fois

     chmod u+x  $HOME/somedir/somescriptname.sh

    dans un terminal. Voir chmod(1) pour la commande et chmod(2) pour le syscall.

    Sauf si vous taper tout le chemin d'accès au fichier, vous devez placer ce fichier dans un répertoire mentionné dans votre PATH (voir environ(7) & execvp(3)), que l'on pourrait définir de façon permanente dans votre ~/.bashrc si votre shell de connexion est bash)

    BTW, vous pouvez écrire votre script dans une autre langue, par exemple en Python et qu'il commence par #!/usr/bin/python, ou en Ocaml, en commençant avec #!/usr/bin/ocaml...

    De l'exécution de votre script en double-cliquant (sur quoi? vous n'avez pas le dire!) est un l'environnement de bureau problème ou de bureau spécifique (qui peut être différente de avec
    Kde, Mate, Gnome, .... ou IceWM ou du poison à rats). Peut-être en lisant EWMH spec peut vous aider à obtenir une meilleure image.

    peut-être faire de votre script exécutable avec chmod pourrait le rendre cliquable sur votre bureau (apparemment, Quartz sur MacOSX). Mais alors vous devriez probablement faire donner des commentaires visuels.

    Et de plusieurs ordinateurs n'ont pas de bureau, y compris votre propre lorsque vous accédez à distance avec ssh.

    Je ne crois pas que c'est une bonne idée d'exécuter votre script shell en cliquant sur. Vous voulez probablement être en mesure de donner des arguments à votre script shell (et comment voudriez-vous faire cela en cliquant sur?), et vous devriez vous préoccuper de sa sortie. Si vous êtes capable d'écrire un script shell, vous êtes en mesure d'utiliser un shell interactif dans un terminal. Qu'il est le meilleur et le plus naturel de façon à utiliser un script. Bonne shell interactif (par exemple, zsh ou les poissons ou peut-être d'une récente bash) ont délicieuse et configurable l'auto-complétion installations et vous n'aurez pas à taper beaucoup (apprendre à utiliser les tab touche de votre clavier). De plus, les scripts et les programmes sont souvent des pièces composites de commandes (canalisations, etc...).

    PS. Je suis à l'aide d'Unix depuis 1986, et Linux depuis 1993. Je n'ai jamais commencé mes propres programmes ou des scripts en cliquant sur. Pourquoi devrais-je?

    • qu'entendez-vous par bureau spécifique?
    • En Double-cliquant sur mon script
    • Mais je ne comprends pas pourquoi vous croyez qu'il apparaîtra sur votre bureau
    • Ok, donc j'ai créé mon script dans un éditeur de texte. J'ai enregistrer le fichier sur mon bureau. Lorsque je clique sur mon script c'est enregistré sur mon bureau, je veux qu'il fait courir sur moi en cliquant sur elle.
    • Je ne sais pas qu'est-ce que votre bureau (KDE, Gnome, MATE, ...). Je vous vous invite à utiliser la ligne de commande dans un terminal, en particulier pour l'exécution de vos scripts (probablement, vous voulez leur donner quelques arguments; comment voulez-vous le faire sur le bureau?). Si vous êtes capable de coder un script shell, vous devriez être en mesure d'utiliser le shell de manière interactive dans un terminal
    • Mon point est que si vous êtes le codage d'un script shell, vous devriez prendre l'habitude d'utiliser une ligne de commande dans un terminal.
    • Je comprends que, pour un projet sur lequel je travaille. Je veux que le script à exécuter une fois cliqué sur. Im essayant d'éviter d'utiliser le terminal pour exécuter le script.
    • Mais sur ce bureau? Vous n'avez pas le dire!
    • Si par desktop-vous dire ce que l'ordinateur je suis en cours d'exécution sur? Im qu'il tourne sur un Macbook Air
    • J'ai des liens vers wikipages sur plusieurs termes.
    • Je ne suis pas encore au courant de la façon de trouver ce que l'environnement de bureau, je suis en utilisant
    • après lecture de votre réponse encore une fois, je comprends tout à fait que vous devez exécuter des scripts bash par la borne, mais c'est pas le point. Je ne suis pas en essayant de trouver un moyen d'exécuter un script bash plus. Je suis spécialement pour vous demander si vous pouvez exécuter des scripts en cliquant sur eux (pour un projet que je suis en train de travailler sur) et Dans le script, je ne suis pas en lui demandant d'afficher quoi que ce soit. Je veux juste exécuter les commandes que j'ai écrit dans le script en cliquant sur le script. rien de graphique apparaît.
    • En général, le "bureau" affiche les fichiers situés dans le $HOME/Desktop répertoire.
    • Peut-être pas sur MacOSX, et un peu de français localisée distributions Linux utilisent $HOME/Bureau au lieu de $HOME/Desktop
    • Pourriez-vous me donner une explication détaillée sur la façon d'utiliser chmod pour éventuellement faire mon script exécutable.
    • vous avez besoin de prendre des heures pour en savoir plus sur l'écriture de scripts. Nous ne pouvons pas vous donner un par un chaque étape.
    • Quand j'ai essayé d'utiliser la commande chmod pour convertir le script exécutable, aucune modification n'est apportée à mon script actuel je ne vois aucun script exécutable
    • Vous avez besoin de beaucoup plus de lecture. chmod ne pas faire de conversion. Il justs drapeaux d'un fichier exécutable. Allez à la bibliothèque et lire quelques bons livres.
    • Je voudrais utiliser chmod +x plutôt que chmod u+x, à moins qu'il n'y a pas de raison particulière pour limiter executability pour le propriétaire.

    InformationsquelleAutor Basile Starynkevitch
  3. 2

    juste .sh.

    Exécuter le script comme ceci:

    ./script.sh

    EDIT: Comme anubhava dit, l'extension n'a pas vraiment d'importance. Mais pour des raisons d'organisation, il est toujours recommandé d'utiliser des extensions.

    • Si vous êtes en cours d'exécution d'un script, en général, vous n'avez aucune raison de se soucier de ce que c'est écrit dans. Un script bash et un binaire exécutable sont exécutés de la même manière. L'ajout d'un .sh suffixe à un script exécutable est généralement inutile d'encombrer.
    • oui, mais comme je l'ai dit dans mon edit - c'est une convention pour organiser les scripts - pas plus?!
    • Je vois beaucoup de scripts avec un .sh extension (et de moins en moins avec un .bash extension), mais je ne suis pas convaincu du tout utile. Si j'ai le nom d'un script foo.sh et plus tard, j'ai décider de ré-écrire en Perl, je peux soit modifier le nom (et l'édition de tout ce qui l'utilise) ou le laisser avec une fausse extension. Si j'ai le nom de ce foo, je n'ai pas ce problème.
    InformationsquelleAutor Marc Anton Dahmen
  4. 2

    Je sais que c'est assez vieux maintenant, mais j'ai l'impression que cela ajoute à ce que la question demandait.

    Si votre sur un mac et vous voulez être en mesure d'exécuter un script en double-cliquant dessus, vous devez utiliser le .command extension. De même qu'avant de rendre le fichier exécutable avec chmod -x.

    Comme l'a souligné avant, ce n'est pas vraiment utile tbh.

    InformationsquelleAutor w_jay
  5. 0

    TL;DR -- Si l'utilisateur (pas nécessairement le développeur du script à l'aide d'une interface graphique, cela dépend de ce fichier navigateur ils utilisent. MacOS Finder nécessitera la .sh extension, pour exécuter le script. Gnome Nautilus, cependant, reconnaît correctement shebanged scripts avec ou sans le .sh extension.

    Je sais que ça a déjà été dit plusieurs fois, les raisons pour et contre l'utilisation d'une extension sur les scripts bash, mais pas autant pourquoi ou pourquoi ne pas utiliser des extensions, mais j'ai ce que je considère être une bonne règle de pouce.

    Si vous êtes le type qui houblon dans et hors de bash et de l'utilisation du terminal en général, ou est le développement d'un outil pour quelqu'un d'autre qui n'utilise pas le terminal, mettez un .sh extension sur votre scripts bash. De cette façon, les utilisateurs de ce script ont la possibilité de double-cliquant sur le fichier dans une interface graphique, navigateur de fichiers pour exécuter le script.

    Si vous êtes le type qui fait tout ou la plupart de votre travail dans le terminal, ne prenez pas la peine de mettre des extension sur votre scripts bash. Ils ne servirait à rien dans le terminal, en supposant que vous avez déjà configuré votre ~/.bashrc fichier à différencier visuellement des scripts à partir de répertoires.

    Edit:

    Dans le Nautilus de Gnome navigateur de fichiers avec 4 fichiers de test (avec les autorisations octroyées pour le fichier à être exécuté) avec stupidement simple commande bash pour ouvrir une fenêtre de terminal (gnome-terminal):

    1. Un fichier SANS extension avec #!/bin/bash sur la première ligne.

      Il a travaillé en double-cliquant sur le fichier.

    2. Un fichier avec un .sh extension avec #!/bin/bash sur la première ligne.

      Il a travaillé en double-cliquant sur le fichier.

    3. Un fichier SANS extension SANS #!/bin/bash sur la première ligne.

      Il a travaillé en double-cliquant sur le fichier...techniquement, mais le GUI a donné aucune indication qu'il a été un script shell. Il a dit que c'était juste un fichier texte.

    4. Un fichier avec un .sh extension SANS #!/bin/bash sur la première ligne.

      Il a travaillé en double-cliquant sur le fichier.

    Cependant, comme Keith Thompson, dans les commentaires de cette réponse, judicieusement souligné, en s'appuyant sur l'aide de la .sh extension au lieu de le bash de cette arborescence sur la première ligne du fichier (#!/bin/bash) il pourrait causer des problèmes.

    L'autre, cependant, je me souviens que lorsque j'étais auparavant à l'aide de MacOS, que même correctement shebanged (est-ce un mot?) scripts bash sans .sh extension n'a pas pu être exécuté à partir de l'interface graphique sur MacOS. J'aimerais que quelqu'un me corriger dans les commentaires si. Si cela est vrai, il s'avère qu'il y a au moins un navigateur de fichier là où la .sh extension de questions.

    • Qui GUI fichier navigateur utilisez-vous (ou, plus pertinemment, que vos utilisateurs utilisent)? Faut-il utiliser l'extension de décider comment exécuter un script?
    • Ainsi, la plate-forme que j'ai le plus d'expérience sur MacOS. Dans le Finder, l'utilisateur décide de apps à associer avec quelle extension. Maintenant, je suis sur Linux avec Gnome, mais je n'ai pas eu l'occasion d'expérimenter comment le Nautilus de Gnome navigateur de fichiers interagit avec les fichiers sans extension encore.
    • Si vous avez un script exécutable avec un .sh suffixe et #!/bin/bash sur la première ligne, est une interface graphique de fichiers le navigateur va utiliser sh de l'invoquer (en ignorant le shebang)? Si oui, cela pourrait causer des problèmes. (La réponse pourrait être différente pour différents navigateurs.)
    • Bons points là-bas. J'ai mis à jour ma réponse ci-dessus avec quelques test je l'ai fait tout à l'heure.
    • Intéressant, mais ... Vous avez dit "travaillé". Pour chacun des 4 cas de test, il serait bon de savoir si il l'invoque avec /bin/bash ou /bin/sh (la dernière est la valeur par défaut pour un script sans shebang). Si /bin/sh est un lien symbolique vers /bin/bash (ce qui est assez commun), alors vous pouvez dire en regardant la valeur de $0. (Aussi, si bash est invoqué comme sh il définit POSIXLY_CORRECT=y.)
    • C'est intéressant. Mon personnel emporter à partir de ce est de toujours inclure à la fois un beau spectacle dans mes scripts et un .sh extension, car le seul inconvénient est qu'il prend plus de 3 caractères. Et je suis tout à fait pour éviter l'ambiguïté dans la mesure du possible.
    • La question est de savoir si le nom du script est un .sh suffixe, ne l'interface graphique de l'exécuter avec /bin/sh ou avec /bin/bash? Si elle utilise bash spécifique et il est invoqué avec /bin/sh, il peut se rompre. Et si l'interface graphique rend compte de l'arborescence, vous pourriez avoir un script Perl appelé foo.sh. Pourquoi spécifier l'interprète de façon incohérente de deux façons différentes?

    InformationsquelleAutor Ryan Hart