Discussion :

[trungsi]

Bonjour,

Mon shell par défaut est ksh.
echo $SHELL : /bin/ksh

Lorsque je lance un script dans le répertoire courant j'ai une erreur :
ksh: test.sh: not found.

Alors que sous bash shell, ça fonctionne correctement.

Quelqu'un a une idée du problème?

Merci

[gangsoleil]

Bonjour,

Pour lancer un script qui est dans le repertoire courant, la bonne commande est :

Code :

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

./mon_script.sh

Le fait que ca fonctionne en bash indique simplement que tu as . dans ton PATH. Cela doit etre ajoute dans le fichier .bashrc ou .bash_profile (ou les deux). Ce n'est pas une bonne habitude que d'avoir . dans son PATH soit dit en passant (pour des raisons de securite notamment, mais aussi parceque ca t'apporte de mauvaises habitudes, et que tu t'apercevras que tes scripts contiennent des erreurs a cause de cela)

[trungsi]

Bonjour,

Merci pour la réponse.

Je sais que ce n'est pas une bonne habitude mais y a t-il un moyen d'ajouter automatiquement le répertoire courant dans le PATH sous ksh?

Car pour l'instant je ne voulais pas modifier tous les scripts qui tournent déjà en prod sous csh. En fait, je dois tester quelques scripts mais la machine de dev est ksh par défaut.

Merci

Bonjour,

Pour lancer un script qui est dans le repertoire courant, la bonne commande est :

Code :

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

./mon_script.sh

Le fait que ca fonctionne en bash indique simplement que tu as . dans ton PATH. Cela doit etre ajoute dans le fichier .bashrc ou .bash_profile (ou les deux). Ce n'est pas une bonne habitude que d'avoir . dans son PATH soit dit en passant (pour des raisons de securite notamment, mais aussi parceque ca t'apporte de mauvaises habitudes, et que tu t'apercevras que tes scripts contiennent des erreurs a cause de cela)

[gangsoleil]

Bonjour,

Avant de l'ajouter définitivement, essaie en faisant un essai local :

Code :

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

export PATH=$PATH/.

Si cela resoud ton probleme, alors il faudra mettre cette ligne dans le fichier que source ksh a son lancement.

[N_BaH]

Je sais que ce n'est pas une bonne habitude

la réponse est dans le texte !


il faudrait y mettre "bon ordre"...
?

[Sve@r]

la réponse est dans le texte !


il faudrait y mettre "bon ordre"...
?

Je voudrais mitiger ce propos.
Le véritable danger du "." dans le PATH se situe uniquement
1) si c'est le PATH de root
2) si le "." se trouve en début de PATH

Dans ce cas, n'importe qui peut faire un clone de "ls" qui va ouvrir certains droits en plus, le mettre dans son répertoire courant et appeler l'admin en faisant croire à un pb. L'admin arrive, passe root et tape naturellement "ls"

Si cela ne concerne pas le PATH de root, alors moins d'ennui puisque celui qui lancera le clone de "ls" n'étant pas root, cela ne nuira pas à la machine. Et si le "." est situé en fin de PATH, alors encore moins de pb puisque taper "ls" lancera alors le vrai programme et non le clone.

Ainsi, c'est uniquement pour éviter la tentation, ou comme on dit "parce que 2 précautions valent mieux qu'une", que par défaut les PATH n'ont pas de ".". Parce que ca ne coûte pas grand chose de taper "./test.sh" au lieu de "test.sh" ou que ça ne coûte pas non plus grand chose de le rajouter si on le désire. Et si vraiment on en veut un, alors tant qu'on ne le met ni en premier, ni au PATH de root, la machine ne risque pas grand chose.

Remarquez que tout ce discours s'appuie essentiellement sur la sauvegarde de la machine. La sauvegarde de l'utilisateur n'entre pas en ligne de compte dans ce développement. Si l'utilisateur est assez nul pour écrire un programme "ls" qui efface tout son HOME, qu'il met le "." en premier dans son PATH et qu'il tape ensuite "ls" ben tant pis quoi. L'important est que la machine reste intègre...

[kalwin]

Si je puis me permettre Sve@r

Je fais un peu de sécurité et je pense que le . dans le PATH pour root comme pour un user normal est dangereux surtout si il est mis au début du PATH

Démonstration à l'appui que j'ai mis en ligne sur ce site ( ici )
C'est mon collègue qui m'a montré ce bug non resolu par IBM
Je ne dévoilerai pas le nom de mon collègue mais seulement ces initial par respect pour lui.

Il est doué et m'aide beaucoup

Merci à toi Nico K.

[Sve@r]

Si je puis me permettre Sve@r

Bien évidemment. C'est toujours agréable de discuter d'Unix avec ceux qui aiment ce système

Je fais un peu de sécurité et je pense que le . dans le PATH pour root comme pour un user normal est dangereux surtout si il est mis au début du PATH

Ok, tu le penses. Bon, tu dis "surtout" s'il est mis au début. Mais qu'en penses-tu s'il est simplement mis à la fin (ce que j'ai préconisé dans mon précédent post) ???

Démonstration à l'appui que j'ai mis en ligne sur ce site ( ici )

Ben j'ai lu la démo. Mais comme le dit gangsoleil, elle ne se rapporte en rien au "." du PATH. Si tu autorises kalwin à aller exécuter le fichier /tmp/kalw.ksh, ben ne t'étonne pas s'il l'exécute !!! Tu ouvres une porte d'entrée via sudoers, faut pas t'étonner si on y entre...

Mon post précédent s'appuyait aussi sur l'axiome (non dit car évident) qu'on se trouve sur un unix un minimum verrouillé...

C'est mon collègue qui m'a montré ce bug non resolu par IBM
Je ne dévoilerai pas le nom de mon collègue mais seulement ces initial par respect pour lui.

Il est doué et m'aide beaucoup

Merci à toi Nico K.

Profites-en. c'est rare d'avoir des potes doués prêts à t'aider