Y a-t-il des problèmes avec les traits d'union dans les fonctions, les alias et les exécutables?

Dans mes tests (dans Bash et Z Shell), je n'ai vu aucun problème avec la définition des fonctions ou des alias ou des scripts shell exécutables qui ont des traits d'union dans le nom, mais je ne suis pas convaincu que tout ira bien dans tous les cas et dans tous les cas d'utilisation .

La raison pour laquelle je voudrais faire ceci est qu'un trait d'union est plus facile à taper qu'un trait de soulignement, et donc plus rapide et plus lisse.

Une des raisons pour lesquelles j'hésite à croire que ce n'est pas un problème est que dans certaines langues (Ruby par exemple), le trait d'union serait interprété comme un signe less même sans espace autour. Cela ne me surprendrait pas si quelque chose comme ça pouvait se produire dans certaines coquilles, où le trait d'union est interprété comme signalant une option même sans espace.

Une autre raison pour laquelle je suis un peu méfiant est que mon éditeur de text corrige la mise en surbrillance de la syntaxe des fonctions avec des traits d'union. (Mais bien sûr, il est tout à fait possible que ce soit juste un bug dans sa syntaxe mettant en évidence la configuration pour les scripts shell.)

Y a-t-il une raison d'éviter les traits d'union?

POSIX et traits d'union: aucune garantie

Selon le standard POSIX, un nom de fonction doit être un nom valide et un nom peut contenir:

3.231 Nom
Dans le langage de command shell, un mot composé uniquement de traits de soulignement, de numbers et d'alphabétiques à partir du jeu de caractères portable. Le premier caractère d'un nom n'est pas un chiffre.

En outre, un alias doit être un nom d'alias valide, qui peut consister en:

3.10 Nom d'alias
Dans le langage de command shell, un mot composé uniquement de traits de soulignement, de numbers et d'alphabétiques du jeu de caractères portable et de l'un des caractères suivants: '!', '%', ',' @ '.

Les implémentations peuvent autoriser d'autres caractères dans les noms d'alias en tant qu'extension. (Soulignement le mien.)

Un trait d'union ne figure pas parmi les caractères qui doivent être autorisés dans les deux cas. Donc, s'ils sont utilisés, la portabilité n'est pas garantie.

Exemples de coquilles qui ne supportent pas les traits d'union

dash est le shell par défaut ( /bin/sh ) de la famille debian-ubuntu et ne prend pas en charge les traits d'union dans les noms de fonction:

 $ ab() { date; } dash: 1: Syntax error: Bad function name

Fait intéressant, il prend en charge les traits d'union dans les alias, bien que, comme indiqué ci-dessus, il s'agit d'une caractéristique d'implémentation , pas une exigence:

 $ a_b() { printf "hello %s\n" "$1"; } $ alias ab='a_b' $ ab world hello world

Le shell busybox (shell Almquist) ne prend pas également en charge les traits d'union dans les noms de fonction:

 $ ab() { date; } -sh: Syntax error: Bad function name

Résumé du soutien Hyphen par Shell

Les shells suivants sont connus pour soutenir les traits d'union dans les noms de fonction:

ksh, bash, zsh

Les shells suivants sont connus pour ne pas prendre en charge les traits d'union dans les noms de fonction:

cendres (busybox), csh, tcsh, tiret

Conclusions

Les traits d'union ne sont pas standard. Éloignez-vous d'eux si vous voulez compatibilité cross-shell.
Utilisez des traits de soulignement au lieu des traits d'union: les traits de soulignement sont acceptés partout.

Je sais que c'est vraiment tard, mais peut-être que vous pouvez contourner votre problème de rendre le soulignement plus accessible.

 xmodmap -e "keycode 20 = underscore minus"

Cela activera le trait de soulignement avec un trait d'union (less).

Alors maintenant, vous maintenez shift pour le trait d'union, mais un trait de soulignement est tapé sans décalage.

Votre keycode peut être différent, cependant, je pense que cela dépend de votre keyboard; le mien se trouve être 20. Faites le moi savoir si vous avez besoin d'aide pour find quel keycode vous devez utiliser.