Discussion :

[lefevrelaumonier]

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

Code :

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

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 :

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

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.

[Winnt]

Bonjour,

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

Code :

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

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

[BufferBob]

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 :

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

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 :

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

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

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

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

[lefevrelaumonier]

voici l'énoncé question 2
Merci à vous
N

[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

[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

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

[disedorgue]

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

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

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

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

[Sve@r]

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

[disedorgue]

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.

[Flodelarab]

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. C'est ça qui t'énerve en fait.

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.

[gangsoleil]

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 :

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

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

Cette méthode fonctionne aussi pour la question 2.

[jack-ft]

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

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

[jack-ft]

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.

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]

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

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]

[jlliagre]

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 :

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

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 :

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

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

[jack-ft]

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!

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

[Sve@r]

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

Non, moi ça m'a fait connaitre hash (que je n'avais jamais utilisé et que je risque de ne jamais utiliser ). 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