Comment créer des commentaires multilignes dans Bash?


226

J'ai récemment commencé à étudier le script shell et j'aimerais pouvoir commenter un ensemble de lignes dans un script shell. Je veux dire comme c'est le cas en C / Java:

/* comment1
   comment2 
   comment3
*/`

Comment pourrais-je faire ça?


2
Vous pouvez utiliser le hachage comme: #ceci est un commentaire.
Mohammad Tayyab

1
Je sais mais c'est un peu gênant pour les multilignes.
Enes Malik Turhan

2
Il convient de noter que les réponses ci-dessous nécessitent que le :soit dans la première colonne (pas d'espaces de tête) de la ligne.
ty

Réponses:


394

Utilisez : 'pour ouvrir et 'fermer.

Par exemple:

: '
This is a
very neat comment
in bash
'

27
:( et ajoute également une grande quantité de non- #
lisibilité

51
@ jm666 IMHO Jamais une bonne idée d'utiliser le mot jamais quand vous n'avez aucune idée de tous les cas d'utilisation.
Hiver

19
expliquer: :est un raccourci trueet truene traite aucun paramètre. (page de manuel:SYNOPSIS true [ignored command line arguments]
phil294

46
L'espace entre :et 'est important
Becko

23
J'ai légèrement modifié cela pour les blocs de code afin que je puisse facilement activer ou désactiver le code. Ma modification consiste à utiliser # 'sur la dernière ligne au lieu du guillemet simple. De cette façon, je peux mettre un single #sur la première ligne pour activer le bloc de code. Retirez la #première ligne pour désactiver le code.
JohnMudd

131

Commentaire multiligne dans bash

: <<'END_COMMENT'
This is a heredoc (<<) redirected to a NOP command (:).
The single quotes around END_COMMENT are important,
because it disables variable resolving and command resolving
within these lines.  Without the single-quotes around END_COMMENT,
the following two $() `` commands would get executed:
$(gibberish command)
`rm -fr mydir`
comment1
comment2 
comment3
END_COMMENT

4
Cela fonctionne, la réponse actuellement acceptée ne fonctionne pas (pour moi).
Freek

5
Il convient probablement de noter que ce n'est pas un commentaire en soi. Il s'agit d'un hérédoc qui est redirigé vers la commande NOP en tant que chaîne multiligne. Le guillemet simple est important pour désactiver la résolution des variables et des commandes.
Nux

1
@Freek a besoin d'ajouter de l'espace
mazs

J'ai testé cela dans un simple script bash qui s'exécute via sa ligne shebang, #! / Bin / bash dans Debian et cela a échoué. J'essaie chaque réponse sur cette page, et elles ont toutes échoué jusqu'à ce que j'arrive à celle ci-dessous. Puisqu'ils ont échoué, je les vote contre et je vote pour celui qui fonctionne correctement.
PyTis

1
De bons tests dans votre exemple. Le leader :n'est pas nécessaire. Commencez avec <<.
wisbucky

34

Je mets à jour ce message en fonction des commentaires et autres réponses, donc les commentaires avant le 22 mai 2020 peuvent ne plus s'appliquer.

Bash ne fournit pas de syntaxe intégrée pour les commentaires sur plusieurs lignes, mais il existe des hacks utilisant la syntaxe bash existante qui "fonctionnent maintenant".

Personnellement, je pense que le plus simple (c'est-à-dire le moins bruyant, le moins bizarre, le plus facile à taper, le plus explicite) est d'utiliser un HEREDOC cité, mais de rendre évident ce que vous faites, et d'utiliser le même marqueur HEREDOC partout:

<<'### BLOCK COMMENT'
line 1
line 2

line 3
line 4
### BLOCK COMMENT

Les guillemets simples du marqueur HEREDOC évitent certains effets secondaires d'analyse du shell, tels que des substitutions étranges qui provoqueraient un plantage ou une sortie, et même une analyse du marqueur lui-même. Ainsi, les guillemets simples vous donnent plus de liberté sur le marqueur de commentaire d'ouverture-fermeture. Par exemple, ce qui suit utilise un hachage triple qui suggère un commentaire sur plusieurs lignes dans bash. Cela ferait planter le script si les guillemets simples étaient absents. Même si vous supprimez ###, le FOO{}ferait planter le script (ou entraînerait une mauvaise substitution à imprimer si non set -e) s'il n'y avait pas les guillemets simples:

set -e

<<'### BLOCK COMMENT'
something something ${FOO{}} something
more comment
### BLOCK COMMENT

ls

Vous pouvez bien sûr simplement utiliser

set -e

<<'###'
something something ${FOO{}} something
more comment
###

ls

mais l'intention de ceci est certainement moins claire pour un lecteur peu familier avec cette supercherie.

De nos jours, tout bon éditeur vous permet d'appuyer sur ctrl- / ou similaire, pour annuler / commenter la sélection. Tout le monde comprend certainement cela:

# something something ${FOO{}} something
# more comment
# yet another line of comment

même s'il est vrai que cela n'est pas aussi pratique que le commentaire de bloc ci-dessus si vous souhaitez remplir à nouveau vos paragraphes.

Il existe sûrement d'autres techniques, mais il ne semble pas y avoir de méthode «conventionnelle». Ce serait bien si ###>et ###<pouvait être ajouté à bash pour indiquer le début et la fin du bloc de commentaires, il semble que cela pourrait être assez simple.


1
Ah, celui-ci est assez facile / propre à retenir!
Thamme Gowda

1
Comme le note la réponse précédente, à part les guillemets, la séquence $ (...) sera également développée car les deux formes sont une substitution de commande.
Perl Ancar

"Les deux sont des hacks afin qu'ils puissent casser des scripts à l'avenir." Pourriez-vous développer cela? Bien que piratant sémantiquement, syntaxiquement, ils sont valides et ne devraient pas se casser à l'avenir, à moins que bash ne décide de devenir fou et de casser les heredocs.
Perl Ancar

@perlancar Si nous convenons que les hacks sont des solutions qui utilisent une fonctionnalité language / lib qui n'est absolument pas liée au problème (comme utiliser un hérédoc pour un commentaire, ou utiliser un paramètre sur une commande de ne rien faire comme true), alors même s'ils ne ne risquez pas de casser (l'approche hérédoc ne le fait pas, mais la version deux points le fait), 1) les hacks obscurcissent toujours l'intention: sans la première ligne faisant allusion au commentaire multiligne, la plupart se gratteraient la tête en se demandant ce que fait ce code; et 2) ont des coins sombres inattendus (comme devoir doubler une citation, citer le marqueur hérédoc dans certains cas, etc.).
Oliver

@Oliver: Si elles ne sont pas citées, les variables peuvent avoir des effets secondaires désagréables. Imaginez que vous avez intégré dans votre hérédoc - commentez une chaîne telle que ${FOO:=bar}ou ${FOO{}}. Le premier peut avoir pour effet secondaire de créer et de définir la variable FOO, le second déclenchera une mauvaise erreur de substitution ; les deux effets que vous n'attendriez pas d'un vrai commentaire.
user1934428

24

Après avoir lu les autres réponses ici, j'ai trouvé ci-dessous, à mon humble avis, il est vraiment clair que c'est un commentaire. Particulièrement adapté aux informations d'utilisation dans le script:

<< ////

Usage:
This script launches a spaceship to the moon. It's doing so by 
leveraging the power of the Fifth Element, AKA Leeloo.
Will only work if you're Bruce Willis or a relative of Milla Jovovich.

////

En tant que programmeur, la séquence de barres obliques s'inscrit immédiatement dans mon cerveau en tant que commentaire (même si les barres obliques sont normalement utilisées pour les commentaires de ligne).

Bien sûr, "////"c'est juste une chaîne; le nombre de barres obliques dans le préfixe et le suffixe doit être égal.


3
J'ai failli rater leUsage:
RNA

Excellent ajout à la réponse ci-dessus. Honnêtement, je pense que vous auriez pu modifier la réponse ci-dessus et l'ajouter au lieu de répondre séparément.
PyTis

Il y a quelques réponses "ci-dessus" (selon votre ordre de tri). Et, en répondant séparément, je voulais expliquer la raison d'être de la chaîne que j'avais choisie.
noamtm

<< EOF ... EOF
l mingzhi

5

quelle est votre opinion sur celui-ci?

function giveitauniquename()
{
  so this is a comment
  echo "there's no need to further escape apostrophes/etc if you are commenting your code this way"
  the drawback is it will be stored in memory as a function as long as your script runs unless you explicitly unset it
  only valid-ish bash allowed inside for instance these would not work without the "pound" signs:
  1, for #((
  2, this #wouldn't work either
  function giveitadifferentuniquename()
  {
    echo nestable
  }
}

bonjour, n'était pas destiné comme une question, plutôt que comme une réponse à la question d'origine
Imre

Pas bon OMI. Cela nécessite que le commentaire soit analysable en tant que code shell, ce qui est assez restrictif.
user1934428

3

Voici comment je fais des commentaires multilignes en bash.

Ce mécanisme présente deux avantages que j'apprécie. La première est que les commentaires peuvent être imbriqués. L'autre est que les blocs peuvent être activés en commentant simplement la ligne de départ.

#!/bin/bash
# : <<'####.block.A'
echo "foo {" 1>&2
fn data1
echo "foo }" 1>&2
: <<'####.block.B'
fn data2 || exit
exit 1
####.block.B
echo "can't happen" 1>&2
####.block.A

Dans l'exemple ci-dessus, le bloc "B" est commenté, mais les parties du bloc "A" qui ne sont pas le bloc "B" ne sont pas commentées.

L'exécution de cet exemple produira cette sortie:

foo {
./example: line 5: fn: command not found
foo }
can't happen

3

J'ai essayé la réponse choisie, mais j'ai découvert que lorsque j'exécutais un script shell, le tout était imprimé à l'écran (similaire à la façon dont les cahiers jupyter imprimaient tout entre '''xx'''guillemets) et il y avait un message d'erreur à la fin. Il ne faisait rien, mais: effrayant . Puis j'ai réalisé en le modifiant que les guillemets simples pouvaient s'étendre sur plusieurs lignes. Donc .. laisse simplement assigner le bloc à une variable.

x='
echo "these lines will all become comments."
echo "just make sure you don_t use single-quotes!"

ls -l
date

'

Pas besoin de l'affecter à une variable, ce qui est un effet secondaire que nous n'attendrions pas d'un «commentaire». Remplacez le x=par un : et vous obtenez le même effet sans effet secondaire. Le seul inconvénient est que le commentaire ne doit alors pas contenir une seule citation. C'est pourquoi je préfère l'utilisation d'un hérédoc entre guillemets: Avec cela, le commentateur peut choisir une chaîne de terminaison appropriée à sa guise.
user1934428

2

Solution simple, pas très intelligente:

Bloquer temporairement une partie d'un script:

if false; then
    while you respect syntax a bit, please
    do write here (almost) whatever you want.
    but when you are
    done # write
fi

Une version un peu sophistiquée:

time_of_debug=false # Let's set this variable at the beginning of a script

if $time_of_debug; then # in a middle of the script  
    echo I keep this code aside until there is the time of debug!
fi

-2

# J'aime la paresse et la simplicité. J'utiliserais # avec une solution de contournement amusante:

1 APPUYEZ SUR:] rechercher ctrl + F ou cmd + F ou autre [pour déclencher la fonctionnalité de recherche

2 utilisez une expression régulière dans le champ de recherche comme: (^.+)

3 remplacer par: # $1ou si vous préférez#$1


# Remarque: vous ne pouvez pas avoir les trois étapes dans votre éditeur. Dans ce cas, utilisez un outil d'expression régulière en ligne (ne pouvez pas en suggérer un ici pour des raisons de politique):

  1. Sélectionnez, copiez le texte où que vous soyez et collez-le dans l'outil d'expression régulière en ligne
  2. Utiliser (^.+)comme regex et #$1ou #\1comme modèles de substitution
  3. Sélectionnez, copiez le texte et collez-le là où vous avez commencé

# Profitez de vos hachages!


De nos jours, de nombreux éditeurs ont le raccourci clavier ctrl+/qui permet d'activer ou de désactiver les commentaires, même pour plusieurs lignes. Il est également capable de modifier le caractère de commentaire en fonction de la langue que vous utilisez.
ninMonkey
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.