Commentant la solution de Ken Bertelson et répondant à Jan Hettich :
Comment cela fonctionne
le site takes_ary_as_arg descTable[@] optsTable[@]
ligne dans try_with_local_arys()
la fonction envoie :
-
Il s'agit en fait de créer une copie de la descTable
y optsTable
qui sont accessibles à la takes_ary_as_arg
fonction.
-
takes_ary_as_arg()
La fonction reçoit descTable[@]
y optsTable[@]
comme des chaînes de caractères, ce qui signifie $1 == descTable[@]
y $2 == optsTable[@]
.
-
au début de takes_ary_as_arg()
il utilise la fonction ${!parameter}
syntaxe, qui est appelée référence indirecte ou parfois double référence ce qui signifie que au lieu d'utiliser $1
nous utilisons la valeur de l'élément élargi valeur de $1
par exemple :
baba=booba
variable=baba
echo ${variable} # baba
echo ${!variable} # booba
de même pour $2
.
-
en mettant cela dans argAry1=("${!1}")
crée argAry1
comme un tableau (les parenthèses qui suivent =
) avec l'extension descTable[@]
J'aime écrire ici. argAry1=("${descTable[@]}")
directement. le site declare
il n'est pas nécessaire.
N.B. : Il convient de mentionner que l'initialisation d'un tableau à l'aide de cette forme de parenthèse initialise le nouveau tableau en fonction de l'option IFS
o Séparateur de champ interne qui est par défaut onglet , nouvelle ligne y espace . dans ce cas, puisqu'il a utilisé [@]
notation, chaque élément est vu par lui-même comme s'il était cité (contrairement aux [*]
).
Ma réserve à son égard
Sur BASH
La portée de la variable locale est la fonction courante et chaque fonction enfant appelée à partir de celle-ci, ce qui se traduit par le fait que takes_ary_as_arg()
La fonction "voit" ces descTable[@]
y optsTable[@]
les tableaux, donc cela fonctionne (voir l'explication ci-dessus).
Dans ce cas, pourquoi ne pas examiner directement ces variables ? C'est comme si on y écrivait :
argAry1=("${descTable[@]}")
Voir l'explication ci-dessus, qui ne fait que copier descTable[@]
en fonction des valeurs actuelles du tableau IFS
.
En résumé
Il s'agit, en substance, de ne rien passer en valeur - comme d'habitude.
Je tiens également à souligner le commentaire de Dennis Williamson ci-dessus : éparses Les tableaux (tableaux dont toutes les clés sont définies - avec des "trous") ne fonctionneront pas comme prévu - nous perdrions les clés et "condenserions" le tableau.
Ceci étant dit, je vois la valeur de la généralisation, les fonctions peuvent donc obtenir les tableaux (ou les copies) sans connaître les noms :
- pour ~"copies" : cette technique est assez bonne, il faut juste être conscient que les indices (clés) ont disparu.
-
pour des copies réelles : on peut utiliser un eval pour les clés, par exemple :
eval local keys=(\${!$1})
et ensuite une boucle les utilisant pour créer une copie. Note : ici !
n'est pas utilisé son évaluation indirecte/double précédente, mais plutôt dans le contexte d'un tableau, il retourne les indices du tableau (clés).
- et, bien sûr, si nous devions passer
descTable
y optsTable
chaînes de caractères (sans [@]
), nous pourrions utiliser le tableau lui-même (comme par référence) avec eval
. pour une fonction générique qui accepte les tableaux.
2 votes
Ici vous avez de belles références et des tonnes d'exemples.
18 votes
Errr... Trois votes négatifs sur une question vieille de cinq ans dans la même minute ?
0 votes
Voici une réponse complète : stackoverflow.com/questions/6212219/
0 votes
En rapport : Passage de paramètres à une fonction Bash
0 votes
Voir aussi : Comment passer un tableau en tant qu'argument d'une fonction en Bash ?
0 votes
Voici la question correspondante pour les "tableaux associatifs" de bash (alias : "dictionnaires", "tables de hachage", ou "cartes non ordonnées") : Comment passer un tableau associatif comme argument à une fonction en Bash ?