Arguments Script Shell

Version imprimable

29/11/2015, 01h19
Marrakchino

Arguments Script Shell

Bonjour, je suis débutant en Shell, et pour le besoin d'un programme je dois pouvoir récupérer (lire) l'argument suivant de chaque argument de la ligne de commande avant de ne passer puisque celui-ci peut contenir une information supplémentaire qu'il faut prendre en compte.
Ex: si l'utilisateur rentre

Code:

./nom_de_mon programme head "il fait beau" tail

, alors mon programme doit interpréter "il fait beau" comme étant un argument propre à head, puis d'autre part prendre en compte le troisième argument: tail.

J'ai essayé plein de fois en parcourant soit la liste d'arguments passés en ligne de commande ($@), soit en bouclant sur le nombre total des arguments ($#) mais en vain.

Merci d'avance.

PS: j'ai passé des heures à feuilleter les discussions sur Google qui ne répondent pas à ma question.
29/11/2015, 02h05
N_BaH

bonjour,

tu veux lire les arguments deux par deux ?
le script n'accepte-t-il que trois arguments ?
le premier argument (par exemple ici : head) a-t-il toujours un "complément" ?

on ne peut pas déterminer a priori si un argument est le "complément" du précédent.
29/11/2015, 09h44
Marrakchino

Citation:

tu veux lire les arguments deux par deux ?

Pas forcément puisqu'il y a des arguments (tail) qui n'ont besoin de rien comme spécification derrière.

Citation:

le script n'accepte-t-il que trois arguments ?

Au total, il peut y en avoir 5.

Citation:

le premier argument (par exemple ici : head) a-t-il toujours un "complément" ?

Non, c'est optionnel en effet.

salut,

il y a une structure assez classique à base de shift pour ce genre de choses qui consiste simplement à consommer les arguments :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 #!/bin/bash while (($#)); do case "$1" in head) echo "option \"head\" reconnue, requiert 1 argument : \"$2\"" shift 2 || break ;; tail) echo "option \"tail\" reconnue, requiert 0 argument." shift ;; "pouet niak") echo "option \"pouet niak\" reconnue, requiert 3 arguments : \"$2\", \"$3\" et \"$4\"" shift 4 || break ;; *) echo "option non-reconnue : \"$1\"" shift ;; esac done
et l'output :
Code:

1 2 3 4 5 6 7 8 $ ./script.sh "pouet niak" coincoin prout gruik toto head "bla pouet" tail burp tail "pouet niak" "niarf coin" "slurp" option "pouet niak" reconnue, requiert 3 arguments : "coincoin", "prout" et "gruik" option non-reconnue : "toto" option "head" reconnue, requiert 1 argument : "bla pouet" option "tail" reconnue, requiert 0 argument. option non-reconnue : "burp" option "tail" reconnue, requiert 0 argument. option "pouet niak" reconnue, requiert 3 arguments : "niarf coin", "slurp" et ""
dès qu'on a plus d'un argument à décaler on s'oblige à une tournure shift x || break, dans le dernier cas par exemple il manque un paramètre pour l'option "pouet niak" et on ne peut décaler que de 3 maximum, shift revient donc avec un code d'erreur, on en profite alors pour sortir de la boucle
malgré ça, utiliser $4 ne pose pas de problème, le paramètre est simplement perçu comme vide, il convient donc de faire des checks additionnels si besoin
$# représente le nombre d'arguments (restants) sur la ligne de commandes, donc while (($#)) "tant que le nombre de paramètres est différent de 0"

29/11/2015, 10h51
Marrakchino

Merci bien à vous BufferBob, j'ai testé et ça marche bien..

Sauf que j'avais une contrainte supplémentaire: l'option head prend un argument optionnel, donc ne requiert pas forcement d'argument derriere.

Comment le tester ? Avec un if après le case head?
29/11/2015, 10h57
disedorgue

Bonjour,

Je te conseillerais de passer par getopts pour gérer tes arguments avec des connecteurs, car l'exemple suivant risque d'être dur à traiter:

Code:

./monprogramme head tail tail

Par contre si tu passe par un connecteur, tu pourrais avoir:

Code:

./monprogramme -e head tail -e tail

Au moins ici, la commande n'est pas ambigu...

C'est bon je m'en suis sorti en incluant un if qui teste si l'argument suivant n'est pas tail ou title, et qui le traite avec le head, en shiftant de deux positions, et d'une seule sinon, lorsqu'aucun argument optionne n'est donné.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
while (($#)); do
    case "$1" in
        head)
            echo "option \"head\" reconnue, requiert 1 argument (optionnel)"
            if [ "$2" = tail ] || [ "$2" = title ]; then
                echo " --> aucun argument supplémentaire"
                shift 1 || break
            else
                echo " --> argument optionnel"
 
                shift 2 || break #on saute donc l'argument optionnel pour
                #passer a l'option qui suit
            fi
 
            ;;
        tail)
            echo "option \"tail\" reconnue, requiert 0 argument."
            echo " ---> \"tail \" reconnue "
            shift
            ;;
        title)
            echo "option \"title\" reconnue, requiert 1 argument : \"$2\""
            echo " ---> \"tail \" reconnue, avec argument \"$2\" "
            shift 2 || break
            ;;
        *)
            echo "option non-reconnue : \"$1\""
            shift
            ;;
    esac
    done

Merci à tous.

29/11/2015, 11h00
Marrakchino

Citation:

Envoyé par disedorgue

Bonjour,

Je te conseillerais de passer par getopts pour gérer tes arguments avec des connecteurs, car l'exemple suivant risque d'être dur à traiter:

Code:

./monprogramme head tail tail

Par contre si tu passe par un connecteur, tu pourrais avoir:

Code:

./monprogramme -e head tail -e tail

Au moins ici, la commande n'est pas ambigu...

Oui j'ai vu le manuel de la commande getopts mais ce qui me gène c'est qu'il faut mettre des arguments de type -a, -b, et je ne dois pas faire ça normalement, ça complique la tâche.
Merci.

Ok, mais ton programme pour le cas suivant ne fonctionne pas correctement car je veux utiliser head avec l'argument "tail":

Code:

1
2
3
4
5
6
7
$ bash ./monpro.sh head "tail" tail
option "head" reconnue, requiert 1 argument optionnel
 --> ici html_head brut
option "tail" reconnue, requiert 0 argument.
 ---> ici: cmd html_tail
option "tail" reconnue, requiert 0 argument.
 ---> ici: cmd html_tail

Alors que si je mets "foo" à la place de "tail" cela fonctionne:

Code:

1
2
3
4
5
$ bash ./monpro.sh head "foo" tail
option "head" reconnue, requiert 1 argument optionnel
 --> ici html_head avec titre optionnel
option "tail" reconnue, requiert 0 argument.
 ---> ici: cmd html_tail

29/11/2015, 11h16
Marrakchino

Je l'ai effectivement remarqué, mais je me suis dit que c'est un cas marginal.. et que ça ne risquait pas de se produire.
je vais y réfléchir.

Merci.
29/11/2015, 18h04
jlliagre

Citation:

Envoyé par Marrakchino

Je l'ai effectivement remarqué, mais je me suis dit que c'est un cas marginal.. et que ça ne risquait pas de se produire.

Ouaip ...

Ce type de raisonnement est la source d'une quantité innombrable de bugs.

Un conseil, soit tu es sûr à 100% que ça ne se produira pas, soit tu traites le cas marginal.
29/11/2015, 20h32
Flodelarab

Bonjour :coucou:

Une fois de plus, la sagesse vient de disedorgue. La façon propre de faire est de passer par la gestion d'arguments.
J'en remets une couche au cas où Marrakchino s'obstine dans sa solution sans avenir.
30/11/2015, 22h38
BufferBob

salut,

au risque de jeter un pavé dans la marre sans avenir, est-ce que l'utilisation de getopts est capable de lever l’ambiguïté d'une invocation du genre ./prog -e head "-e" -e tail (cas marginal, mais qu'il convient de gérer à priori) ?

qui plus est getopts dans l'exemple proposé ne va du coup gérer qu'un unique switch -e si je comprends bien, quelqu'un est en mesure de proposer une implémentation histoire de voir ce que ça donne ?

je m'fais un peu l'avocat du ~~diable~~PO mais pour moi il a décrit une problématique assez précise, et son cas marginal est géré, pas de manière ultime certes, mais c'est géré, et si en plus on attend de lui qu'il ait une syntaxe flat sans option -x, -xxx ou --xxx ou autre /x, je vois pas tellement d'autre possibilité que l'exemple que j'ai donné plus haut

Edit: pour rappel, getopt (builtin) ne gère pas les paramètres avec des espaces et n'est pas conseillé à l'utilisation et getopts ne gère pas les options longues, sinon il faut utiliser getopt (GNU), mais aucun ne gère plus d'un paramètre pour le switch, en l'occurrence ici c'est head qui est censé être l'option et prendre un paramètre optionnel...

Il est vrai que via les options courtes c'est un peu galère à gérer (d'ailleurs les commandes standards ne le gèrent pas) mais via des options longues on pourrait le faire sous une forme de syntaxe comme l'exemple ci-dessous:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
$ ./monprog.bash --head --tail
Option: '--head' sans valeur
Option: '--tail' sans valeur
$ ./monprog.bash --head="titi va a la plage" --tail="bob"
Option: '--head' valeur = titi va a la plage
Option: '--tail' ne prend pas de valeur
$ ./monprog.bash --head="titi va a la plage" --tail="bob" --title
Option: '--head' valeur = titi va a la plage
Option: '--tail' ne prend pas de valeur
Option: '--title' doit avoir une valeur
$ ./monprog.bash --head="titi va a la plage" --tail="bob" --title="marley"
Option: '--head' valeur = titi va a la plage
Option: '--tail' ne prend pas de valeur
Option: '--title' valeur = marley
$ ./monprog.bash --head="--title" --tail="bob" --title="marley"
Option: '--head' valeur = --title
Option: '--tail' ne prend pas de valeur
Option: '--title' valeur = marley

Pour celui qui est interressé, voici le bout de code:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
$ cat monprog.bash 
OPTIONS="h-:"
while getopts $OPTIONS OPTNAME
do
	case $OPTNAME in
		-)
			case "${OPTARG}" in
				head)
					echo "Option: '--${OPTARG}' sans valeur" 
					;;
				head=*)
					echo "Option: '--${OPTARG%=*}' valeur = ${OPTARG#*=}"
					;;
				tail)
					echo "Option: '--${OPTARG}' sans valeur" 
					;;
				tail=*)
					if [[ "$OPTERR" = 1 ]] && [[ "${OPTIONS:0:1}" != ":" ]]; then
						echo "Option: '--${OPTARG%=*}' ne prend pas de valeur" >&2
					fi
					;;
				title)
					if [[ "$OPTERR" = 1 ]] && [[ "${OPTIONS:0:1}" != ":" ]]; then
						echo "Option: '--${OPTARG}' doit avoir une valeur" >&2
					fi
					;;
				title=*)
					echo "Option: '--${OPTARG%=*}' valeur = ${OPTARG#*=}"
					;;
				*)
					if [[ "$OPTERR" = 1 ]] && [[ "${OPTIONS:0:1}" != ":" ]]; then
						echo "Option --${OPTARG} inconnue" >&2
					fi
					;;
			esac
			;; 
		*)
			if [[ "$OPTERR" = 1 ]] && [[ "${OPTIONS:0:1}" != ":" ]]; then
				echo "Option $OPTNAME inconnue" >&2
			fi
			;;
	esac
done

Ici, le h (qui aurait pu être une autre lettre) dans la variable OPTIONS est juste là pour que getopts ne sort pas en erreur en disant que le '-' est invalide...
Et si on met le caractère ":" en tout début dans la variable OPTIONS, nous n'aurons plus l'affichage d'erreur tel que:
--tail ne prend pas de valeur
ou
--title doit avoir une valeur

oui c'est ce que je disais, le getopts ici n'est d'aucun secours, puisqu'il ne sert qu'à gérer le -, d'ailleurs tu gères les paramètres optionnels manuellement au final, et getopts ne sait pas gérer les options longues, il faut aller chercher GNU getopt (lien)

si l'ambiguïté ne portait que là dessus, la même chose sans getopt(s) :
Code:

1 2 3 4 5 6 7 8 9 10 while (($#)); do case "$1" in "--head") echo "Option: \"$1\" sans valeur";; "--head="*) echo "Option: \"${1%=*}\" valeur = \"${1#*=}\"";; "--tail") echo "Option: \"$1\" sans valeur";; "--title="*) echo "Option: \"${1%=*}\" valeur = \"${1#*=}\"";; *) echo "Option non-conforme : \"$1\"" >&2;; esac shift done
et le résultat :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 $ ./pouet.sh --head --tail Option: "--head" sans valeur Option: "--tail" sans valeur $ ./pouet.sh --head="titi va a la plage" --tail="bob" Option: "--head" valeur = "titi va a la plage" Option non-conforme : "--tail=bob" $ ./pouet.sh --head="titi va a la plage" --tail="bob" --title Option: "--head" valeur = "titi va a la plage" Option non-conforme : "--tail=bob" Option non-conforme : "--title" $ ./pouet.sh --head="titi va a la plage" --tail="bob" --title="marley" Option: "--head" valeur = "titi va a la plage" Option non-conforme : "--tail=bob" Option: "--title" valeur = "marley" $ ./pouet.sh --head="--title" --tail="bob" --title="marley" Option: "--head" valeur = "--title" Option non-conforme : "--tail=bob" Option: "--title" valeur = "marley"
du coup le = est primordial et il ne doit pas y avoir d'espace entre l'option et sa valeur, c'est un détail qui a son importance et qui peut être signifié à l'utilisateur à travers une option --help par exemple, tout comme on aurait pu dire qu'on choisi une syntaxe option1 paramètre_optionnel où le nombre d'espaces importe peu et en précisant simplement que paramètre_optionnel ne peut pas prendre la valeur "option2" ou "option3", le tout étant de faire son choix et de l'assumer par la suite
on notera par ailleurs qu'on est pas non plus tenu à une syntaxe --option=valeur et que option=valeur fonctionnerait tout aussi bien pour le coup

et en bonus, le parsing manuel permet d'envisager éventuellement des options prenant plusieurs valeurs, là où getopt(s) ne le permettra pas

tout ça pour dire que le PO mérite pas forcément le goudron et les plumes d'une part, et d'autre part que getopt(s) n'est pas forcément un réflexe incontournable, sorte de best practice à avoir lorsqu'il s'agit de parser les arguments en bash

01/12/2015, 10h46
disedorgue

Au moins, ce qui me rassure, c'est que cela montre que je suis loin d'être sage :ptdr:

Après, passer par getopt(s), ou pas, à chacun de choisir: j'apprécie ton propos sur le sujet car je croyais être le seul à me demander la réelle utilité de ces commandes ;)
Mais je ne suis pas vraiment pour de bousculer la convention du passage d'options sans les signes "-" pour les courtes et "--" pour les longues.

Pour ce qui est du goudron et des plumes, je ne me sent pas concerné.

PS: le fait de dire créer un usage, ou de le signaler d'une manière ou d'une autre, c'est ce qui s'appelle de géré le cas, non ? :aie:

Citation:

Envoyé par disedorgue

je ne suis pas vraiment pour de bousculer la convention du passage d'options sans les signes "-" pour les courtes et "--" pour les longues.

non moi non plus, après tout dépend des contraintes de l'exercice disons, on pourrait aussi envisager qu'au lieu d'options il s'agit de mots clés pour un simili-langage par exemple
Code:

1 2 3 ./dessine triangle x0 y0 x1 y1 x2 y2 point x y ligne x0 y0 x1 y1 ... ./tortue avance 50 tourne G 30 avance 18 tourne D 70 ... ./expression appeler caroline ginette chloe vanessa puis acheter chapeaux puis ambiance "barry white"
Citation:

PS: le fait de dire créer un usage, ou de le signaler d'une manière ou d'une autre, c'est ce qui s'appelle de géré le cas, non ? :aie:

yep, tout à fait :)

01/12/2015, 17h01
jack-ft

Citation:

Envoyé par BufferBob

mots clés pour un simili-langage par exemple

Code:

./tortue avance 50 tourne G 30 avance 18 tourne D 70 ...

Turtle geometry? (que de souvenirs!)
01/12/2015, 18h00
BufferBob
Citation:

Envoyé par jack-ft

Turtle geometry? (que de souvenirs!)

ouai, pas vraiment en fait (la syntaxe était différente de mémoire) mais c'était l'idée ;)
- https://fr.wikipedia.org/wiki/Logo_(langage)