L'utilisation de caractères Unicode étendus est (sans aucun doute) utile pour de nombreux utilisateurs.
Les shells plus simples (ash (busybox), dash) et ksh échouent avec:
tést() { echo 34; }
tést
Mais bash , mksh , lksh et zsh semblent le permettre.
Je suis conscient que les noms de fonction valides POSIX utilisent cette définition des noms . Cela signifie que cette expression régulière:
[a-zA-Z_][a-zA-Z0-9_]*
Cependant, dans le premier lien, il est également dit:
Une implémentation peut autoriser d'autres caractères dans un nom de fonction en tant qu'extension.
Les questions sont:
- Est-ce accepté et documenté?
- Où?
- Pour quels obus (le cas échéant)?
Questions connexes:
Son possible utiliser des caractères spéciaux dans un nom de fonction shell?
Je ne suis pas intéressé à utiliser des méta-caractères (>) dans les noms de fonction.
Noms de fonction Upstart et bash contenant "-"
Je ne pense pas qu'un opérateur (soustraction "-") doive faire partie d'un nom.
alias
un peu plus clément. et vous pouvez donc écrire la fonction avec un nom approprié et boutonné, puis définir simplement un alias nommé plus élégamment pour appeler la fonction. dansdash
il y a aussi des choses que vous pouvez faire avec$PATH
et%func
.Réponses:
Étant donné que la documentation POSIX l'autorise en tant qu'extension, rien n'empêche l'implémentation de ce comportement.
Une simple vérification (rodée
zsh
):montrer que
bash
,zsh
,yash
,ksh93
(quiksh
lié à mon système),pdksh
et sa dérivation permettent des caractères multi-octets comme nom de la fonction.yash
est conçu pour prendre en charge les caractères multi-octets dès le début, il n'y a donc pas de surprise que cela fonctionne.L'autre documentation que vous pouvez consulter est
ksh93
:Donc, paramétrer sur
C
locale:faire échouer.
la source
posh
ne vaut pas d'être répertorié dans une telle liste. Cela dépend des bogues spécifiques à Linuxlibc
et ne fonctionnera pas sur d'autres plates-formes.ksh93
utilisation d'un ksh93 auto-compilé à partir de sources originales. Bien qu'ilksh88
semble accepter des lettres ASCII non 7 bits pour les noms de fonction, seul leksh93
binaire d'Ubuntu semble les accepter.Notez que les fonctions partagent le même espace de noms que d'autres commandes, y compris les commandes du système de fichiers, qui sur la plupart des systèmes n'ont aucune limitation sur les caractères ou même les octets qu'elles peuvent contenir dans leur chemin.
Ainsi, alors que la plupart des shells restreignent les caractères de leurs fonctions, il n'y a aucune vraie bonne raison pour laquelle ils feraient cela. Cela signifie que dans ces shells, il existe des commandes que vous ne pouvez pas remplacer par une fonction.
zsh
etrc
autoriser quoi que ce soit pour leurs noms de fonction, y compris certains avec/
et la chaîne vide.zsh
autorise même les octets NUL.Une commande simple dans le shell est une liste d'arguments, et le premier argument est utilisé pour dériver la commande à exécuter. Il est donc logique que ces arguments et noms de fonction partagent les mêmes valeurs possibles et que les arguments des fonctions
zsh
intégrées et des fonctions puissent être n'importe quelle séquence d'octets.Il n'y a pas de problème de sécurité ici car les fonctions que vous (l'auteur du script) définissez sont celles que vous invoquez.
Là où il peut y avoir des problèmes de sécurité, c'est lorsque l'analyse est affectée par l'environnement, par exemple avec des shells où les noms valides pour les fonctions sont affectés par les paramètres régionaux.
la source
function /bin/sh { echo "$0: $FUNCNAME: Permission denied"; return 126; }
, et potentiellement choses utiles aussi avec des fonctions nommées--
,//
,@
ou%
etc./
on le trouve dans un nom? et une fonction n'est pas seulement un nom exécutable - son code. Je pense qu'une simple implémentation pourrait rencontrer beaucoup de problèmes d'analyse si ses noms de fonction stockés comprenaient des métacaractères.