Posté par Marotte ⛧ .
En réponse au journal Args parser pour shell.
Évalué à 7.
Dernière modification le 16 février 2024 à 01:59.
Pas vraiment pris de le temps de regarder de près mais je pense que je le ferai. Juste lu le README, il y a une chose qui me fait tiquer :
auxilium_parse $@
Ne pas mettre de double quotes ici n’est-ce pas à coup sûr le meilleur moyen qu’une valeur passée à une option telle que 'j’ai un espace yo!' ou "moi aussi !" foute le bordel ?
Si j’ai bien compris :
"$@"
a la particularité de se « développer » (? pas sûr du terme...) en "element1" "element2" "element3" ... etc... alors que sans les doubles quotes, il est strictement équivalent à $*, et se développera en element1 element2 element3 ..., donc sans quote entourant chaque élément.
Jamais eu autant de prise tête avec les échappements en Python, j’ai l’impression qu’en shell c’est une des difficulté majeure de bien comprendre en quoi ''""$'' sont différents, et que IFS est un élément clé (et strict mode pas une chose de seconde importance...).
J’ai des souvenirs d’en arriver parfois à des triples échappement jadis... or il n’y a que le double échappement qui puisse être justifié dans certains cas, assez rares, mais quand tu triples échappe faut aller prendre l’air et faire une sieste ! ^^
Au sujet de IFS, j’ai jamais compris l’utilisation d’un OLDIFS pour rétablir le truc après eu besoin de le modifier. Quand j’ai besoin de le modifier c’est généralement pour un un read, et en faisant IFS='caractère ad-hoc' read ... à la suite du read IFS a toujours sa valeur. _o_ (\t\n bien sûr ! pour ceux qui suivent)
Comme on peut faire par exemple, dans un shell interactif : LANG=C man bash si on a habituellement sa locale en fr mais qu’on veut lire la sainte bible en anglais. Ça ne va pas changer la valeur de LANG pour les commandes suivante, juste pour la commande qui suit l’affectation (un truc que j’ai eu du mal à capter à mes débuts clairement)...
# Quoting
Posté par Marotte ⛧ . En réponse au journal Args parser pour shell. Évalué à 7. Dernière modification le 16 février 2024 à 01:59.
Pas vraiment pris de le temps de regarder de près mais je pense que je le ferai. Juste lu le README, il y a une chose qui me fait tiquer :
auxilium_parse $@Ne pas mettre de double quotes ici n’est-ce pas à coup sûr le meilleur moyen qu’une valeur passée à une option telle que
'j’ai un espace yo!'ou"moi aussi !"foute le bordel ?Si j’ai bien compris :
a la particularité de se « développer » (? pas sûr du terme...) en
"element1" "element2" "element3" ...etc... alors que sans les doubles quotes, il est strictement équivalent à$*, et se développera enelement1 element2 element3 ..., donc sans quote entourant chaque élément.Jamais eu autant de prise tête avec les échappements en Python, j’ai l’impression qu’en shell c’est une des difficulté majeure de bien comprendre en quoi
''""$''sont différents, et queIFSest un élément clé (et strict mode pas une chose de seconde importance...).J’ai des souvenirs d’en arriver parfois à des triples échappement jadis... or il n’y a que le double échappement qui puisse être justifié dans certains cas, assez rares, mais quand tu triples échappe faut aller prendre l’air et faire une sieste ! ^^
Au sujet de IFS, j’ai jamais compris l’utilisation d’un OLDIFS pour rétablir le truc après eu besoin de le modifier. Quand j’ai besoin de le modifier c’est généralement pour un un
read, et en faisantIFS='caractère ad-hoc' read ...à la suite du read IFS a toujours sa valeur. _o_ (\t\nbien sûr ! pour ceux qui suivent)Comme on peut faire par exemple, dans un shell interactif :
LANG=C man bashsi on a habituellement sa locale en fr mais qu’on veut lire la sainte bible en anglais. Ça ne va pas changer la valeur de LANG pour les commandes suivante, juste pour la commande qui suit l’affectation (un truc que j’ai eu du mal à capter à mes débuts clairement)...