Exécution commande shell

Version imprimable

09/01/2015, 15h08
lefevrelaumonier

Exécution commande shell
Bonjour,
je suis débutant avec les commandes shell.
J'ai l'arborescence de départ suivante :
Code:

1 2 3 4 5 bin / groupe1 / prog1.sh bin / groupe1 / prog2.sh bin / groupe2 / prog1.sh bin / groupe2 / prog2.sh
Tous les fichiers ont les droits en lecture et exécution pour tous les utilisateurs.

Code:

PATH = /bin/groupe2:/bin/groupe1

Je cherche une suite de commence à mettre dans le terminal pour faire que si j'exécute :
prog1.sh c'est celui du groupe1 qui s’exécute
prog2.sh c'est celui du groupe2 qui s’exécute

J'avais penser retirer les droits d’exécution de prog2.sh dans groupe1 et ceux de prog1.sh dans groupe2 mais je ne suis pas convaincu.

Encore une fois je suis débutant. :)
Je regarde cette matière dans le cadre d'un diplôme en maths.
Merci beaucoup
N.
09/01/2015, 15h44
Winnt
Bonjour,

Il ne serai pas plus simple en ce cas d'avoir cette architecture ? :
Code:

1 2 bin / groupe1 / prog1.sh bin / groupe2 / prog2.sh

salut,

dans l'absolu il y a plusieurs façons de faire, retirer les droits d'exécution sur bin/groupe1/prog2.sh et bin/groupe2/prog1.sh peut effectivement être envisageable à priori

on pourrait aussi créer des alias :
Code:

1 2 alias prog1='bin/groupe1/prog1.sh' alias prog2='bin/groupe2/prog2.sh'
(note qu'on peut y compris aliaser directement prog{1,2}.sh avec l'extension inclue au besoin)

et selon le contexte/les contraintes, ce que je trouve plus propre personnellement, c'est d'avoir une arborescence du style :
Code:

1 2 3 4 5 6 7 8 9 10 repertoire_parent/ +-- bin/ | +-- prog1.sh --> ../groupe1/prog1.sh # \_ liens symboliques | +-- prog2.sh --> ../groupe2/prog2.sh # / +-- groupe1/ | +-- prog1.sh | +-- prog2.sh +-- groupe2/ +-- prog1.sh +-- prog2.sh
et une variable PATH=repertoire_parent/bin en gros

09/01/2015, 16h58
lefevrelaumonier

Effectivement, je suis d'accord qu il serait plus simple de changer l'architecture mais comme je disais, je suis dans un contexte d'un exercice théorique (cours) et je n'ai pas de latitude sur l'architecture de l'arborescence.

Je vais tester le concept d'alias. Cela à l'air plutôt intéressant.
Merci beaucoup
N.
09/01/2015, 17h19
disedorgue

Bonjour,

Bizarre comme exercice, tu peux nous montrer l'énoncer ?

La solution de l'arborescence avec les liens proposée par BufferBob est en principe la plus adaptée:
-Pas besoin de créer des alias à tout le monde pour fonctionner.
-C'est le principe utilisé pour géré les versions des librairies par exemple.
-Le défaut principal de l'alias, tu ne peux l'appeler depuis un script.
09/01/2015, 17h58
lefevrelaumonier

1 pièce(s) jointe(s)

voici l'énoncé question 2
Merci à vous
NPièce jointe 165810
09/01/2015, 19h40
disedorgue

Pour la question 1, tu n'as pas le droit de toucher à la variable PATH, donc la solution de rajouter des liens au niveau de /bin ne peut se faire, par contre pour la question 2, ce n'est pas spécifié, donc il serait concevable de le faire...

Mais ton idée de départ est tout aussi valable, le système n' exécutera que des commandes qui sont marquées comme étant exécutables.

Selon moi, si tu as résolu la question 1, tu peux t'en inspirer fortement, d'ailleurs tu peux aussi nous donner ta solution :)
09/01/2015, 20h00
lefevrelaumonier

Merci beaucoup pour votre aide.
Je vais présenté plusieurs solutions dans mon devoir :)

Pour la 1, j'utilise simplement le nom absolu du fichier dans la console du terminal.
Comme je disais , c'est un cours de "débutant" l'objectif est de faire simple :)

merci pour votre aide.
Je reviendrai sans doute durant le WE pour d'autres questions
10/01/2015, 11h25
Sve@r

Bonjour

Sans déconner, ils ont quand-même des questions tordues ces profs. "sans modifier la variable PATH". Pourquoi ne pas demander "sans vous servir de vos deux jambes, expliquez comment courir le 110m haies en justifiant de vos réponses". Si on part dans des hypothèses débiles, il y en aura des milliers de réponses (on peut prendre une moto, un tapis volant, etc...)

Ceci dit, la réponse de BufferBob ne convient pas (j'ai testé). Si on supprime les droits d'exécution aux commandes, et qu'on appelle "commande1.sh", le shell répond "groupe1/commande1.sh permission denied" et ne va absolument pas chercher celles de "groupe2".
Donc ben mettre le chemin complet lors de l'appel serait pour moi ce qu'il y a de plus simple (on ne modifie pas l'environnement de l'utilisateur par des alias ni l'environnement de la machine par des liens symboliques). Mais on n'est pas obligé de mettre le chemin en absolu ; on peut aussi le mettre en relatif ("../groupe1/commande1.sh" par exemple...)

Si cela fonctionne, le fait que cela ne fonctionne pas est lié à un cache, pour s'en convaincre:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
$ echo $PATH
./bin/groupe1:./bin/groupe2:./bin/groupe3:/usr/local/sbin:/usr/local/bin:/usr/bin:/opt/android-sdk/platform-tools:/opt/android-sdk/tools:/usr/bin/vendor_perl:/usr/bin/core_perl
$ commande1.sh 
./bin/groupe1/commande1.sh
$ chmod -x bin/groupe1/commande1.sh 
$ commande1.sh 
bash: ./bin/groupe1/commande1.sh: Permission non accordée
$ export PATH=$PATH
$ commande1.sh 
./bin/groupe2/commande1.sh
$ chmod +x bin/groupe1/commande1.sh 
$ commande1.sh 
./bin/groupe2/commande1.sh
$ export PATH=$PATH
$ commande1.sh 
./bin/groupe1/commande1.sh

PS: Pour ceux qui on besoin d'un code des différentes commande{1,2,3}.sh pour le test, voici celui que j'utilise:

Code:

1
2
3
#!/usr/bin/bash
 
echo $0

10/01/2015, 14h59
Sve@r

Citation:

Envoyé par disedorgue

Si cela fonctionne, le fait que cela ne fonctionne pas est lié à un cache

J'avais aussi cette impression mais j'avais pas trop d'idée pour tester cette hypothèse. Hormis fermer ma fenêtre shell (mais blasé par la question j'étais vraiment pas motivé). Réutiliser le PATH actuel est un joli truc...

Donc autre réponse possible (c'était mon idée première quand j'ai testé): enlever le droit "x" au dossier "groupe1/bin" lui-même. Pas de droit "x", pas de déplacement possible dans le dossier donc pas accès aux commandes qui s'y trouvent. C'est bien plus minimum comme opération qu'enlever le droit "x" aux différents scripts...
10/01/2015, 15h26
disedorgue

Citation:

Envoyé par Sve@r

Donc autre réponse possible (c'était mon idée première quand j'ai testé): enlever le droit "x" au dossier "groupe1/bin" lui-même. Pas de droit "x", pas de déplacement possible dans le dossier donc pas accès aux commandes qui s'y trouvent. C'est bien plus minimum comme opération qu'enlever le droit "x" aux différents scripts...

Oui, pour la question 1, faut le faire sur les répertoires groupe2,groupe3 et juste le droit "x" pour respecter la clause minimum, mais pour la question 2, faut le faire sur les fichiers eux-même.
11/01/2015, 16h29
Flodelarab

Citation:

Envoyé par Sve@r

Sans déconner, ils ont quand-même des questions tordues ces profs

Hum. C'est peut-être que le prof a plus de connaissances que toi et qu'il fait naturellement un truc que tu as du mal à faire avec tout ce que tu sais. :oops: C'est ça qui t'énerve en fait. :lol:

J'ai peut-être compris la question de travers mais il s'agit de préséance. Il n'est pas question d'interdire l'exécution. Un peu comme un 'which' qui renvoie l'application qui est vraiment exécutée dans un liste d'applications possibles. Je n'ai pas la réponse.
13/01/2015, 18h06
gangsoleil

Citation:

Envoyé par Flodelarab

Hum. C'est peut-être que le prof a plus de connaissances que toi et qu'il fait naturellement un truc que tu as du mal à faire avec tout ce que tu sais.

Je ne remets pas en cause les connaissances du professeur, mais je suis d'accord avec Sve@r : si on souhaite garantir l'exécution de /bin/groupe2/commandeI.sh, la bonne manière pour le faire "dans la vraie vie" est de s'assurrer que PATH contient /bin/groupe2 avant tous les autres /bin/groupeI.
La méthode qui consiste à utiliser le chemin absolu est bonne, mais ne permet pas du tout de garantir que si un utilisateur appelle "commandeI.sh", ce sera celle de /bin/group2/ qui sera exécutée.

D'ailleurs, je ne suis pas certain que l'utilisation du chemin absolu réponde à la question 1. Pour moi, il faut soit modifier le PATH, soit utiliser la commande alias pour chaque commande :

Code:

alias commande1.sh='/bin/group2/commande1.sh

Cette méthode fonctionne aussi pour la question 2.
14/01/2015, 10h20
jack-ft

Citation:

Envoyé par Sve@r

J'avais aussi cette impression mais j'avais pas trop d'idée pour tester cette hypothèse. Hormis fermer ma fenêtre shell (mais blasé par la question j'étais vraiment pas motivé). Réutiliser le PATH actuel est un joli truc...

Dans le temps, quand on modifiait quelque chose comme chmod +x toto.sh, pour que ce soit pris en compte, il fallait faire rehash, mais il semble que cette commande n'existe plus :koi:
14/01/2015, 17h02
Sve@r

Hum, j'ai connu beaucoup d'Unix divers, mais je n'ai jamais eu à faire ça. Et je trouve rien à ce sujet sur google. Peut-être que ça se passait pour toi sur un truc exotique. Ou peut-être aussi que les Unix que j'ai connus (Xenix, Solaris) étaient eux des trucs exotiques.
C'est bien de parler du bon vieux temps. Ca fait très "professeur londonien du XIX°". Moi je me souviens du jour où j'ai vu un lien symbolique. Je me disais "punaise qu'est-ce que c'est que ce nouveau truc"...:mrgreen:
18/01/2015, 22h01
jack-ft

Citation:

Envoyé par Sve@r

Hum, j'ai connu beaucoup d'Unix divers, mais je n'ai jamais eu à faire ça. Et je trouve rien à ce sujet sur google. Peut-être que ça se passait pour toi sur un truc exotique. Ou peut-être aussi que les Unix que j'ai connus (Xenix, Solaris) étaient eux des trucs exotiques.

Pour autant que je m'en souvienne, il s'agissait soit d'un VAX 780 sous UNIX (BSD 4.1 ou 4.2, je crois) soit d'une SUN 2 sous SunOS/SunView.
Et on faisait bien des "rehash" pour voir prises en compte certaines modifs.

Citation:

C'est bien de parler du bon vieux temps. Ca fait très "professeur londonien du XIX°".

Ben, en fait, je n'ai pas très bien connu le XIX° (j'étais trop jeune)...

[HS]

Citation:

Moi je me souviens du jour où j'ai vu un lien symbolique. Je me disais "punaise qu'est-ce que c'est que ce nouveau truc"...:mrgreen:

Moi, je me souviens de l'installation de netfs sur les Sun: plus besoin de se rloguer d'une machine sur une autre pour retrouver son home!
[/HS]

Citation:

Envoyé par jack-ft

Pour autant que je m'en souvienne, il s'agissait soit d'un VAX 780 sous UNIX (BSD 4.1 ou 4.2, je crois) soit d'une SUN 2 sous SunOS/SunView.
Et on faisait bien des "rehash" pour voir prises en compte certaines modifs.

Sous Ultrix ou SunOS, le shell par défaut était csh et "reshash" est une builtin de csh. L'équivalent sous les shells de type Bourne est "hash -r" et c'est une commande qui est toujours d'actualité.

Dans le cas où une commande déjà présente dans un autre répertoire moins prioritaire du PATH et déjà exécutée par le shell apparaît dans un autre répertoire du PATH, il est nécessaire, par exemple sous bash (mais pas sous ksh), de vider le cache de la table de hachage du shell pour qu'il choisisse la "bonne" commande.

Ceci est valable quel que soit l'OS, exotique ou pas.

Exemple:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 $ echo $PATH /var/tmp:/usr/bin:/bin:/tmp $ ls -l /var/tmp/cmd1 -rwxr-xr-x 1 jlliagre jlliagre 24 janv. 18 23:24 /var/tmp/cmd1 $ cmd1 cmd1 dans /tmp $ /var/tmp/cmd1 cmd1 dans /var/tmp $ cmd1 cmd1 dans /tmp $ hash -r $ cmd1 cmd1 dans /var/tmp
Pour répondre à la question initiale, il est possible de forcer bash à ignorer l'ordre des répertoires du PATH à l'aide de la commande (assez tordue j'en conviens) suivante :

Code:

hash -p /bin/groupe1/prog1.sh prog1.sh

19/01/2015, 23h07
jack-ft

Citation:

Envoyé par jlliagre

Sous Ultrix ou SunOS, le shell par défaut était csh et "reshash" est une builtin de csh.

Effectivement! Maintenant que tu le dis, je me souviens avoir utilisé le csh à mes débuts! :bravo:

Je suis désolé pour la confusion que j'ai pu apporter. :oops:
20/01/2015, 08h17
Sve@r

Citation:

Envoyé par jack-ft

Je suis désolé pour la confusion que j'ai pu apporter. :oops:

Non, moi ça m'a fait connaitre hash (que je n'avais jamais utilisé et que je risque de ne jamais utiliser :P). C'est vrai, ça m'arrive tous les jours d'avoir une commande dans un dossier en fin de PATH puis d'en créer une autre de même nom dans un dossier en début de PATH et de vouloir avoir immédiatement accès à cette nouvelle commande en oubliant l'ancienne :lol:
20/01/2015, 08h48
jlliagre

Ça n'arrive pas tous les jours mais quand ça arrive on peut être surpris, d'autant plus que tous les shells ne réagissent pas de façon identique ...

Une autre façon de vider ce cache consiste à réaffecter le PATH, ex:

Code:

PATH="$PATH"