Discussion :

[crodilus]

Bonsoir à toutes et à tous

Je dois écrire un petit script qui reçoit en paramètre des commandes et des flags. On prend l'hypothèse ou le premier paramètre est une commande et que l'on ne trouve jamais deux flags qui se suivent.

Ex : sh exercice1.sh ls -l pwd

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
#!/bin/bash
#Exercice1
 
 
while [ $# -ne 0 ]
do
case $# in
"$2"=-*) $1$2 
	 shift 2;;
*) $1 
   shift;;
esac
done

Malheureusement ça ne marche pas. Je sais que l'erreur vient d'ici

Code :

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

"$2"=-*)

J'aimerais trouver un moyen de dire au bash " si le paramètre 2 comporte un tiret comme premier caractère alors tu exécutes la commande et son flag.

Je croyais que l'étoile pouvait remplacer n'import quelle suite de caractère mais apparemment ce n'est que valable pour les fichiers et répertoires ?

Si quelqu'un aurait une idée ? Elle est la bienvenue !

Amicalement crodilus.

[Sve@r]

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
#!/bin/bash
#Exercice1
 
 
while [ $# -ne 0 ]
do
case $# in
"$2"=-*) $1$2 
	 shift 2;;
*) $1 
   shift;;
esac
done

Malheureusement ça ne marche pas. Je sais que l'erreur vient d'ici

Code :

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

"$2"=-*)

Salut
Manifestement tu n'as pas pigé comment fonctionne un case.
Un case permet de comparer un élément X avec plusieurs possibilités. Par exemple comparer X avec "tata" ou "toto"

Code bash :

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

1
2
3
4
case X in
    "tata") ...;;
    "toto") ...;;
esac

Toi déjà tu regardes $# (le nombre d'arguments ???) et tu demandes au shell de voir donc si ce nombre vaut "$2"=-*. Il est bien incapable de piger ce que tu veux lui faire faire (déjà que moi j'ai du mal...)

J'aimerais trouver un moyen de dire au bash " si le paramètre 2 comporte un tiret comme premier caractère alors tu exécutes la commande et son flag.

Code bash :

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

test $(echo $2 |cut -c1) = "-" && $1 $2

Je croyais que l'étoile pouvait remplacer n'import quelle suite de caractère mais apparemment ce n'est que valable pour les fichiers et répertoires ?

Ca dépend du contexte. Effectivement si ton shell est en train de manipuler des fichiers et qu'il tombe sur une étoile, il regardera alors tous les fichiers du répertoire correspondant et vérifiera si leur nom matche la chaine. En revanche, dans un case, il regardera simplement l'élément X matche la chaine

Si quelqu'un aurait une idée ? Elle est la bienvenue !

Bah je suis le premier mais tous les autres habitués de cette section auront aussi des idées sûrement toutes plus brillantes les unes des autres (surtout N_Bah qui m'épate chaque fois qu'il pond une ligne mais c'est probablement parce qu'il développe à fond les possibilités bash alors que moi je suis obligé de rester dans du shell compatible sh)...

[crodilus]

Effectivement je n'avais pas compris grand chose au fonctionnement du case !

Mais grâce à ton intervention j'ai trouvé une solution qui fonctionne !

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
#!/bin/bash
#Exercice1
 
 
while [ $# -ne 0 ]
do
var=`echo $2 |cut -c1`
case $var in
  "-") $1 $2 
     shift 2;;
  *) $1 
     shift;;
esac
done

[Obsidian]

Hello !

Ça fonctionne et ça a l'avantage d'être valable sur tous les Unices. Cependant, « cut » est une commande externe.

La man page nous apprend en revanche que bash propose l'opérateur « =~ » utilisable avec « [[ ]] ». Donc :

Code bash :

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

    [[ $i =~ -.* ]] && echo "La variable i débute par un tiret."

Apparemment, en utilisant les doubles crochets, il est inutile de protéger l'expression avec des guillemets et/ou de lui adjoindre un préfixe pour gérer le cas de la chaîne vide.

[jabbounet]

Pourquoi ne pas utiliser getops?

Quelques liens sur le sujet.

http://www.shellunix.com/ksh.html#Getopts


http://www.developpez.net/forums/d32.../bash-getopts/

[crodilus]

Hello !

Ça fonctionne et ça a l'avantage d'être valable sur tous les Unices. Cependant, « cut » est une commande externe.

La man page nous apprend en revanche que bash propose l'opérateur « =~ » utilisable avec « [[ ]] ». Donc :

Code bash :

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

    [[ $i =~ -.* ]] && echo "La variable i débute par un tiret."

Apparemment, en utilisant les doubles crochets, il est inutile de protéger l'expression avec des guillemets et/ou de lui adjoindre un préfixe pour gérer le cas de la chaîne vide.

Si c'est plus portable pourquoi pas ? !

Pourquoi ne pas utiliser getops?

Quelques liens sur le sujet.

http://www.shellunix.com/ksh.html#Getopts


http://www.developpez.net/forums/d32.../bash-getopts/

A vrai dire je ne fais que du linux depuis trois mois donc je ne connais pas encore grand chose.

[N_BaH]

Bonjour,

La man page nous apprend en revanche que bash propose l'opérateur « =~ » utilisable avec « [[ ]] ». Donc :

Code :

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

[[ $i =~ -.* ]] && echo "La variable i débute par un tiret."

une regex n'est pas indispensable, un simple glob fait le boulot :

Code :

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

[[ $i == -* ]] && echo "La variable i débute par un tiret."

Crodilus:
n'exécute pas un script bash en l'appelant avec sh, car alors, c'est sh (qui peut être un alias vers bash, ou pas!!!) qui exécutera les commandes du script.

[crodilus]

n'exécute pas un script bash en l'appelant avec sh, car alors, c'est sh (qui peut être un alias vers bash, ou pas!!!) qui exécutera les commandes du script.

Que me conseilles-tu alors ? !

[N_BaH]

il est d'usage de rendre le script exécutable et de l'appeler avec son chemin.
si le chemin n'est pas dans le PATH
et que le script est dans le répertoire courant : ./scripts'il est dans un autre répertoire : cheminRelatif/vers/script, ou /cheminAbsolu/vers/script

[Sve@r]

Mais grâce à ton intervention j'ai trouvé une solution qui fonctionne !

Code :

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

1
2
3
4
5
6
case `echo $2 |cut -c1` in
  "-") $1 $2 
     shift 2;;
  *) $1 
     shift;;
esac

Pas mal (avec même une petite optimisation possible pour éliminer $var). Tu as su utiliser mon exemple et l'adapter dans un autre contexte. Mais tu aurais pris le temps de réfléchir à ma phrase sur l'étoile et tu aurais trouvé encore mieux

Code :

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

1
2
3
4
5
6
7
case $2 in
  -*) $1 $2 
     shift 2
     ;;
  *) $1 
     shift
esac

PS: le double point-virgule n'est pas utile pour la dernière option du case et, conventionnellement, comme cette dernière option est très souvent "*" on aime bien, si c'est l'étoile, alors ne pas le mettre (élégance de code)

Que me conseilles-tu alors ? !

et que le script est dans le répertoire courant : ./scripts'il est dans un autre répertoire : cheminRelatif/vers/script, ou /cheminAbsolu/vers/script

Plus universellement cheminVersScript/script, le token "cheminVersScript" pouvant être (comme tout chemin Unix) un chemin absolu ou relatif ; et si c'est un chemin relatif, pouvant être alors "." signifiant "répertoire courant".
Donc pour toi, ça devrait probablement être ./exercice1.sh ls -l pwd (mais faut avoir pensé à rendre le fichier exercice1.sh exécutable car ils ne l'est pas par défaut => chmod a+x exercice1.sh).

Etant donné que tu fais débuter ton script par #!/bin/bash, le script embarque avec lui son interpréteur. Dès qu'il est invoqué, c'est Unix qui se charge donc d'appeler le bon interpréteur...

Pourquoi ne pas utiliser getops?

J'y ai pensé aussi. Mais outre le fait que getopts est fait pour chercher des options à partir du premier argument et s'arrêter dès qu'un argument n'est plus une option (dans ce cas il s'arrête donc au "ls" et ne chope pas le "-l"), comme il s'agit manifestement d'un exercice (probablement destiné à faire manipuler les arguments pour être à l'aise avec $1, $2, $# et $*) je pense que ça ne serait pas profitable de passer par un outil spécialisé.
En plus getopts est fait pour que le programmeur sache que son script a été appelé avec telle option pour lui faire faire telle action mais ici manifestement, qu'il y ait "-l" ou "-a" importe peu puisque le script renvoie le problème à la commande en dessous (ici "ls")...

Mais c'est bien de l'évoquer pour plus tard...

[crodilus]

Pas mal (avec même une petite optimisation possible pour éliminer $var). Tu as su utiliser mon exemple et l'adapter dans un autre contexte. Mais tu aurais pris le temps de réfléchir à ma phrase sur l'étoile et tu aurais trouvé encore mieux

Code :

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

1
2
3
4
5
6
7
case $2 in
  -*) $1 $2 
     shift 2
     ;;
  *) $1 
     shift
esac

PS: le double point-virgule n'est pas utile pour la dernière option du case et, conventionnellement, comme cette dernière option est très souvent "*" on aime bien, si c'est l'étoile, alors ne pas le mettre (élégance de code)

Effectivement en me pressant de chercher la solution j'ai fait quelqu'un chose d'un peu plus long !

Plus universellement cheminVersScript/script, le token "cheminVersScript" pouvant être (comme tout chemin Unix) un chemin absolu ou relatif ; et si c'est un chemin relatif, pouvant être alors "." signifiant "répertoire courant".
Donc pour toi, ça devrait probablement être ./exercice1.sh ls -l pwd (mais faut avoir pensé à rendre le fichier exercice1.sh exécutable car ils ne l'est pas par défaut => chmod a+x exercice1.sh).

Etant donné que tu fais débuter ton script par #!/bin/bash, le script embarque avec lui son interpréteur. Dès qu'il est invoqué, c'est Unix qui se charge donc d'appeler le bon interpréteur...

La console me met permission non accordée et pourtant je suis bien en root !

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
#!/bin/bash
#Exercice1
 
chmod a+x exercice1.sh
 
while [ $# -ne 0 ]
do
case $2 in
  -*) $1 $2 
     shift 2;;
    *) $1 
     shift
esac
done

Ce n'est pas bon ?

Ça marche !

[Sve@r]

La console me met permission non accordée et pourtant je suis bien en root !

Mal. On ne travaille jamais sous root et ce pour 3 raisons
1) tu es sensé oeuvrer dans un monde collaboratif. Or si ton travail marche sous root, peut-être qu'il marche parce qu'il a certains privilèges et donc rien ne dit qu'il marchera dans un compte lambda. Les autres risquent de ne pas pouvoir utiliser ton travail
2) la très grande résistance d'Unix face aux virus vient du fait que toute tâche exécutée prend les privilèges de celui qui l'exécute. Ainsi même le pire des tchernobyl lancé par un utilisateur lambda ne pourra pas toucher autre chose que les fichiers de l'utilisateur. Ca peut certes être grave pour l'utilisateur mais la priorité de l'admin est de protéger sa machine qui reste, elle, intègre. En revanche, lancer sous root même le plus bénin des ver et ça fera des ravages...
3) juste pour que ça te rentre bien dans la tête. Les bonnes habitudes se prennent de suite comme ça on a moins de mal à les perdre...

Code bash :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
#!/bin/bash
#Exercice1
 
chmod a+x exercice1.sh
 
while [ $# -ne 0 ]
do
case $2 in
  -*) $1 $2 
     shift 2;;
    *) $1 
     shift
esac
done

Ce n'est pas bon ?

Pas tout à fait. Déjà le script n'est pas forcément là où tu te trouves donc si tu es ailleurs, la commande chmod ne trouvera plus le fichier "exercice.sh" (qui est ici nommé de façon relative).
Il peut en plus changer de nom plus tard. Dommage si ton script se nomme ensuite "work.sh"...
Donc théoriquement la bonne syntaxe serait chmod a+x $0 (après tout, si $0 existe, autant l'utiliser...)
De plus, pour que ce chmod soit exécuté il faut que le script soit exécuté donc qu'il soit déjà... exécutable. Ainsi puisqu'il a déjà le flag x, inutile de le lui remettre.
Conclusion instruction inutile. Cette commande chmod est à taper depuis ta console après que tu aies fini d'écrire ton script et quand tu te prépares à l'exécuter pour le tester ; pas dans le script lui-même...

[Obsidian]

Mal. On ne travaille jamais sous root et ce pour 3 raisons
1) tu es sensé oeuvrer dans un monde collaboratif. Or si ton travail marche sous root, peut-être qu'il marche parce qu'il a certains privilèges et donc rien ne dit qu'il marchera dans un compte lambda. Les autres risquent de ne pas pouvoir utiliser ton travail
2) la très grande résistance d'Unix face aux virus vient du fait que toute tâche exécutée prend les privilèges de celui qui l'exécute. Ainsi même le pire des tchernobyl lancé par un utilisateur lambda ne pourra pas toucher autre chose que les fichiers de l'utilisateur. Ca peut certes être grave pour l'utilisateur mais la priorité de l'admin est de protéger sa machine qui reste, elle, intègre. En revanche, lancer sous root même le plus bénin des ver et ça fera des ravages...

Ce qu'il faut surtout dire, c'est qu'il faut considérer root comme un pseudo-utilisateur et pas comme le compte « Administrateur » de Windows (c'est lui, surtout, qui a fait des ravages dans le cerveau de l'utilisateur).

Utiliser root, ce n'est pas s'accorder toutes les permissions sur sa machine, mais lever tous les garde-fous qu'elle met en place.

[crodilus]

Mal. On ne travaille jamais sous root et ce pour 3 raisons
1) tu es sensé oeuvrer dans un monde collaboratif. Or si ton travail marche sous root, peut-être qu'il marche parce qu'il a certains privilèges et donc rien ne dit qu'il marchera dans un compte lambda. Les autres risquent de ne pas pouvoir utiliser ton travail
2) la très grande résistance d'Unix face aux virus vient du fait que toute tâche exécutée prend les privilèges de celui qui l'exécute. Ainsi même le pire des tchernobyl lancé par un utilisateur lambda ne pourra pas toucher autre chose que les fichiers de l'utilisateur. Ca peut certes être grave pour l'utilisateur mais la priorité de l'admin est de protéger sa machine qui reste, elle, intègre. En revanche, lancer sous root même le plus bénin des ver et ça fera des ravages...
3) juste pour que ça te rentre bien dans la tête. Les bonnes habitudes se prennent de suite comme ça on a moins de mal à les perdre...


Conclusion instruction inutile. Cette commande chmod est à taper depuis ta console après que tu aies fini d'écrire ton script et quand tu te prépares à l'exécuter pour le tester ; pas dans le script lui-même...

Bien reçu !

Mais en appelant mon script en tant qu'utilisateur et avec un chemin absolut comme-ci:

./home/user1/exercice1.sh pwd ls -l

C'est propre ainsi ?

Ce qu'il faut surtout dire, c'est qu'il faut considérer root comme un pseudo-utilisateur et pas comme le compte « Administrateur » de Windows (c'est lui, surtout, qui a fait des ravages dans le cerveau de l'utilisateur).

Utiliser root, ce n'est pas s'accorder toutes les permissions sur sa machine, mais lever tous les garde-fous qu'elle met en place.

Merci pour la nuance, j'y voie plus clair maintenant !

[Sve@r]

Mais en appelant mon script en tant qu'utilisateur et avec un chemin absolut comme-ci:

./home/user1/exercice1.sh pwd ls -l

Ce n'est pas un chemin absolu puisque son nom ne commence pas par un "/" (il y a un point avant).
Donc cette commande ne fonctionnera que si tu te trouves dans un dossier contenant le fichier "./home/user1/exercice1.sh". A priori seul "/" correspond à cette contrainte...

C'est propre ainsi ?

Tu as tout à fait le droit d'indiquer le chemin de ton script de toutes les façons que t'offre ton environnement de travail
De façon absolue:
/home/user1/exercice1.sh pwd ls -l
/home/././../home/user1/./exercice1.sh pwd ls -l

De façon relative (mais comme chaque fois qu'on utilise un nom relatif il faut toujours savoir où on se trouve on va imaginer que tu es dans "/home/user1"):
./exercice1.sh pwd ls -l
../user1/exercice1.sh pwd ls -l
../user1/../user1/exercice1.sh pwd ls -l

Tu as même le droit de ne pas indiquer son chemin si ledit chemin est déjà positionné dans le PATH:
exercice1.sh pwd ls -l