Est-il possible de vérifier une syntaxe de script bash sans l'exécuter?
En utilisant Perl, je peux courir perl -c 'script name'
. Existe-t-il une commande équivalente pour les scripts bash?
Est-il possible de vérifier une syntaxe de script bash sans l'exécuter?
En utilisant Perl, je peux courir perl -c 'script name'
. Existe-t-il une commande équivalente pour les scripts bash?
Réponses:
bash -n scriptname
Peut-être une mise en garde évidente: cela valide la syntaxe mais ne vérifie pas si votre script bash essaie d'exécuter une commande qui n'est pas sur votre chemin, comme à la ech hello
place de echo hello
.
set
font.
if ["$var" == "string" ]
au lieu deif [ "$var" == "string" ]
type [
dit "[est un shell intégré". Il délègue finalement au test
programme, mais il s'attend également à une clôture. Donc c'est comme if test"$var"
, ce qui n'est pas ce que l'auteur voulait dire, mais qui est syntaxiquement valide (disons que $ var a une valeur de "a", alors nous verrons "bash: testa: commande introuvable"). Le point est que syntaxiquement, il n'y a pas d'espace manquant.
[
n'est invoquée dans ce cas que si elle $var
se développe sur une chaîne vide . Si se $var
développe en une chaîne non vide , [
est concaténé avec cette chaîne et est interprété comme un nom de commande (pas un nom de fonction ) par Bash, et, oui, c'est syntaxiquement valide, mais, comme vous le dites, évidemment pas l'intention. Si vous utilisez à la [[
place de [
, même s'il [[
s'agit d'un mot clé shell (plutôt que d'un mot clé intégré), vous obtiendrez le même résultat, car la concaténation de chaîne involontaire remplace toujours la reconnaissance du mot clé.
["$var"
est syntaxiquement une expression de nom de commande valide ; de même, les jetons ==
et "$string"
sont des arguments de commande valides . ( En général, builtin [
est analysé avec commande syntaxe, tandis que [[
- comme une coquille mot - clé - est analysé différemment.) La commande interne shell [
ne pas déléguer au « test
programme » (utilitaire externe): bash
, dash
, ksh
, zsh
tous ont intégré les versions des deux [
ettest
et ils n'appellent pas leurs homologues externes.
Le temps change tout. Voici un site Web qui fournit une vérification de la syntaxe en ligne pour le script shell.
J'ai trouvé qu'il est très puissant pour détecter les erreurs courantes.
ShellCheck est un outil d'analyse statique et de peluchage pour les scripts sh / bash. Il est principalement axé sur la gestion des erreurs de syntaxe et des pièges de niveau débutant et intermédiaire typiques lorsque le shell donne simplement un message d'erreur cryptique ou un comportement étrange, mais il signale également quelques problèmes plus avancés où les cas d'angle peuvent provoquer des échecs retardés.
Le code source de Haskell est disponible sur GitHub!
apt-get install shellcheck
trusty-backports
.
J'active également l'option 'u' sur chaque script bash que j'écris afin de faire des vérifications supplémentaires:
set -u
Cela signalera l'utilisation de variables non initialisées, comme dans le script suivant 'check_init.sh'
#!/bin/sh
set -u
message=hello
echo $mesage
Exécution du script:
$ check_init.sh
Rapportera les éléments suivants:
./check_init.sh[4]: mesage: paramètre non défini.
Très utile pour attraper les fautes de frappe
set -u
bien que cela ne réponde pas vraiment à la question, car vous devez exécuter le script pour obtenir le message d'erreur. Ne bash -n check_init.sh
montre même pas cet avertissement
sh -n script-name
Lance ça. S'il y a des erreurs de syntaxe dans le script, il renvoie le même message d'erreur. S'il n'y a pas d'erreur, il sort sans donner de message. Vous pouvez vérifier immédiatement en utilisant echo $?
, qui retournera 0
confirmant le succès sans aucune erreur.
Cela a bien fonctionné pour moi. J'ai couru sous Linux OS, Bash Shell.
sh -n
ne vérifiera probablement pas que le script est un script Bash valide. Cela pourrait donner de faux négatifs. sh
est une variante du shell Bourne qui n'est généralement pas Bash. Par exemple dans Ubuntu Linux realpath -e $(command -v sh)
donne / bin / dash
Je vérifie en fait tous les scripts bash dans le répertoire actuel pour les erreurs de syntaxe SANS les exécuter à l'aide de l' find
outil:
Exemple:
find . -name '*.sh' -exec bash -n {} \;
Si vous souhaitez l'utiliser pour un seul fichier, modifiez simplement le caractère générique avec le nom du fichier.
Il existe un plugin BashSupport pour IntelliJ IDEA qui vérifie la syntaxe.
.sh
ou une autre extension associée aux scripts Bash, ce qui est le cas si vous générez les scripts à l'aide d'un outil de modélisation comme ERB (puis ils se terminent par .erb
). Votez pour youtrack.jetbrains.com/issue/IDEA-79574 si vous voulez le réparer!
Si vous avez besoin dans une variable de la validité de tous les fichiers d'un répertoire (git pre-commit hook, build lint script), vous pouvez attraper la sortie stderr des commandes "sh -n" ou "bash -n" (voir autres réponses) dans une variable, et avoir un "si / autre" basé sur cette
bashErrLines=$(find bin/ -type f -name '*.sh' -exec sh -n {} \; 2>&1 > /dev/null)
if [ "$bashErrLines" != "" ]; then
# at least one sh file in the bin dir has a syntax error
echo $bashErrLines;
exit;
fi
Changez "sh" par "bash" selon vos besoins