Petit bash bien ennuyeux !

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:

---

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:

---

"$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.

Citation:

---

Envoyé par crodilus

Code:

---

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:

---

"$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:

---

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...)

Citation:

---

Envoyé par crodilus

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:

---

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

---

Citation:

---

Envoyé par crodilus

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

Citation:

---

Envoyé par crodilus

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)...

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:

---

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

---

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:

---

[[ $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.

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/

Citation:

---

Envoyé par 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:

---

[[ $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 ? !

Citation:

---

Envoyé par 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/

---

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

Bonjour,

Citation:

---

Envoyé par Obsidian

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

Code:

---

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

---

---

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

Code:

---

[[ $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.

Citation:

---

Envoyé par N_BaH

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 ? !

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

Citation:

---

Envoyé par crodilus

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

Code:

---

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:

---

1 2 3 4 5 6 7

case $2 in -*) $1 $2 shift 2 ;; *) $1 shift esac

---

:mrgreen::mrgreen::mrgreen:

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)

Citation:

---

Envoyé par crodilus

Que me conseilles-tu alors ? !

Citation:

---

Envoyé par N_BaH

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...

Citation:

---

Envoyé par jabbounet

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...:ccool:

Citation:

---

Envoyé par Sve@r

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:

---

1 2 3 4 5 6 7

case $2 in -*) $1 $2 shift 2 ;; *) $1 shift esac

---

:mrgreen::mrgreen::mrgreen:

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 :oops: !

Citation:

---

Envoyé par Sve@r

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).

Citation:

---

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:

---

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 :) !

Citation:

---

Envoyé par crodilus

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...

Citation:

---

Envoyé par crodilus

Code:

---

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...

Citation:

---

Envoyé par Sve@r

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.

Citation:

---

Envoyé par Sve@r

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 ?

Citation:

---

Envoyé par Obsidian

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 !

Citation:

---

Envoyé par crodilus

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...

Citation:

---

Envoyé par crodilus

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