Discussion :

[Sve@r]

qui ne m'avance absolument pas, ne voyant pas du tout de quoi on parle : quels arguments restants ? Quels paramètres de position ?

Quand tu crées un programme pour qu'il effectue une tâche, tu peux le prévoir pour que les élements nécessaire à sa tâche lui soient passés lors de l'appel. Exemple le programme "cp" recevra deux éléments de travail: la source et la destination.
Ces éléments sont passés après le nom du programme et avant le <return>. On les nommes "arguments du programme" => cp toto titi.

Du côté programme, ces élements sont stockés dans des variables numérotées "$1", "$2", "$3", etc. qu'on nomme "paramètres de position" de par l'évidente corrélation entre les numéros des variables (1, 2, 3, etc) et la liste des arguments reçu (premier, second, troisième, etc). Ainsi dans l'exemple, "$1" contient "toto" et "$2" contient "titi". Plus "$#" qui contient le nombre d'arguments (ici 2), plus "$*" qui contient tous les arguments sous forme de chaine unique (donc "toto titi") et "$@" qui contient tous les arguments sous forme de chaines individuelles (donc "toto" "titi"). Plus "$0" qui contient le nom du programme tel qu'il a été invoqué en ligne de commande (ici "cp")
Ce stockage est automatique. C'est bash qui le fait lors de l'appel.

La commande set permet de réaffecter manuellement toutes ces variables. Si par exemple tu tapes l'instruction set xxx yyy zzz alors avant l'instruction tu as "$1" qui contient "toto", après l'instruction tu as "$1" qui contient "xxx" (et pareil pour tous les autres). Sauf "$0" qui reste inchangé.

Ca peut être utile par exemple pour explorer ton chemin pwd. Tu tapes IFS=/ set "$(pwd)" et tu as tout ton pwd explosé dans $1, $2, $3, etc...

[Invité]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
$ (IFS='/' set -- "$(pwd)"; printf '%s\n' "$@")
/home/nbah

[Sve@r]

/home/nbah

Oui, tu as raison. J'ai écrit cet exemple en partant d'un de mes codes mais j'ai voulu l'adapter à une syntaxe que j'ai apprise récemment dans laquelle on écrit var=valeur instruction et dans laquelle la variable n'existe que pour l'instruction.
Donc je l'ai tapée sans la tester, en partant du principe que ça allait fonctionner puisqu'elle me semblait similaire à celle de mon code. Or après examen/test effectivement elle ne fonctionne pas.

Voici un exemple créé à partir de mon code d'origine qui, lui, fonctionne

Code bash :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
#!/bin/bash
 
oldifs="$IFS"
IFS="/"
set $(pwd)
IFS="$oldifs"
 
echo "[$1]"
echo "[$2]"
echo "[$3]"

Et si on shunte maintenant la phase "sauvegarde puis restauration de l'IFS" en raccourcissant tout ça via un IFS=/ set $(pwd) ça ne fonctionne plus. Je ne peux que dire "désolé je ne sais pas pourquoi" mais c'est un peu de ta faute, c'est toi qui m'a appris var=valeur instruction

Bon enfin c'est pas vraiment grave, l'important c'est que Jipété comprenne l'idée que mon exemple a voulu exprimer.

PS: a noter aussi que si on remplace set $(pwd) par set "$(pwd)" là non plus ça ne fonctionne pas. Ok là c'est ma faute, j'ai voulu appliquer mes principes de quoter systématiquement toute string mais il semble que ça s'accorde mal avec l'IFS (et les quotes n'y sont d'ailleurs pas dans mon code d'origine )

PS2: le code en question est disponible sur ce forum... https://frederic-lang.developpez.com...divers#LXIII-I

PS3: en fait je pense que je n'ai pas compris var=valeur instruction car quand je tape toto=123 echo "[$toto]" j'obtiens "[]"

[disedorgue]

IFS = Input Field Separator

Donc, pour des commandes internes au shell qui ne prennent pas de données en entrée (le cas de set), ça ne fonctionne pas, faut que la variable soit changée pour le shell en lui même car c'est lui qui prend l'entrée pour fournir les paramètres à la commande.

Cela fonctionne pour "read" car lui attend bien quelque chose en entrée.

Question: pourquoi "$(pwd)" et pas la variable "$PWD" ?