Vous n'êtes pas identifié(e).
Ok parce que ce n'est pas un paramètre de position,
mais grrrrrrrrr, les valeurs des arguments d'une commande sont bien quelque part, en plus il faut les mettre dans le bon ordre ?
Du point de vue de l'enregistrement de leurs valeurs, c'est quoi la différence entre les arguments d'une commande et les paramètres de position, par exemple posé avec set dans un script ?
Merci d'avance
Dernière modification par Hypathie (06-06-2014 05:11:25)
Hors ligne
Tu peux essayer
pour avoir le dernier argument de la dernière commande.
NB: quant au rôle que vient jouer set là dedans, aucune idée
captnfab,
Association Debian-Facile, bépo.
TheDoctor: Your wish is my command… But be careful what you wish for.
Hors ligne
puis :
retour:
Autrement dit l'argument donné à bash c'est le chemin de la commande touch.:cool:
ha ouais super merci !
NB: C'est vrai je me suis mal expliquée. Je suis gênée par la ressemblance suivante,
là si on donne au script deux arguments a et b par exemple, l'exécution du script permet d'en récupérer la valeur $1 et $2, du coup ils ressemblent à des paramètres de position, comme lorsque avec set on fait :
Mais dans l'autre sens il n'y a plus cette sorte de "correspondance" avec le programme du script, et on ne peut pas avoir accès au paramètre de position du script, si je lance le deuxième script ci-dessus dans un terminal et que, dans le même terminal, je fais tout de suite après son exécution :
le retour est un saut de ligne.
Je ne comprends pas pourquoi, et je me demande comment récupérer des paramètres de position d'un script pour qu'ils deviennent les argument d'un script ou d'une commande ?
Hors ligne
Autrement dit l'argument donné à bash c'est le chemin de la commande touch.:cool:
Pas tout à fait non.
Dans un premier temps, ton terminal est lancé, genre /usr/bin/gnome-terminal
Celui-ci lance le shell, via la commande indiquée dans le fichier /etc/passwd, à la fin de la ligne commençant par ton nom d'utilisateur.
Par défaut, la ligne en question est /bin/bash.
Donc, bash se comporte un peu comme un script bash, et si tu lui demandes quel est son argument 0, il te donne la commande qui a été utilisée pour le lancer, sans les arguments.
Je suis gênée par la ressemblance suivante,
#!/bin/bash
if [ $# == 1 ] ; then
echo "erreur: vous avez entré $@, il en faut deux"
elif [ $# == 2 ] ; then
echo "les arguments que vous avez entrés sont $1 et $2
fi
là si on donne au script deux arguments a et b par exemple, l'exécution du script permet d'en récupérer la valeur $1 et $2, du coup ils ressemblent à des paramètres de position, comme lorsque avec set on fait :
#!/bin/bash
set a b c
echo $1 $2 $3
En effet, visiblement, la commande «set» permet de redéfinir les arguments passés au script, pendant l'exécution de celui-ci. Ça me semble dans le meilleur des cas à éviter absolument
Mais dans l'autre sens il n'y a plus cette sorte de "correspondance" avec le programme du script, et on ne peut pas avoir accès au paramètre de position du script, si je lance le deuxième script ci-dessus dans un terminal et que, dans le même terminal, je fais tout de suite après son exécution :
echo $1
le retour est un saut de ligne.
Mhh, non, ça ne fonctionne pas comme ça.
Voyons avec un dessin.
Bon, on m'a toujours dit que je dessinais mal et qu'il fallait que je lâche le compas et la règle pour dessiner des poissons, mais, voilà, tu saisis l'idée
captnfab,
Association Debian-Facile, bépo.
TheDoctor: Your wish is my command… But be careful what you wish for.
Hors ligne
Hors ligne