juste un petit probleme :
Quand j'essaye de me logguer avec un "rsh" sur une machine distante , tout
se passe bien
a une exception pret, le rsh ne semble pas lire mon $HOME/.profile de cette
meme machine distante
pourquoi ??
ex: rsh machineB -l test "echo $<une var. definie sur l'autre machine dans
/home/test/.profile>"
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
TiChou
Dans le message <news:c8c771$ghj$, *ste* tapota sur f.c.o.l.configuration :
Salut à tous,
Bonjour,
juste un petit probleme : Quand j'essaye de me logguer avec un "rsh" sur une machine distante , tout se passe bien a une exception pret, le rsh ne semble pas lire mon $HOME/.profile de cette meme machine distante pourquoi ??
ex: rsh machineB -l test "echo $<une var. definie sur l'autre machine dans /home/test/.profile>"
C'est un « problème » de shell, pas un problème du fonctionnement de rsh. Prenons l'exemple du shell bash. Quand celui-ci est lancé comme un shell de login, il lira dans l'ordre les fichiers /etc/profile, ~/.bash_profile, ~/.bash_login et ~/.profile s'ils existent bien sûr. Quand bash est lancé comme un shell interactif, c'est le cas avec la commande 'rsh -l user host commande', il ne lira que le fichier ~/.bashrc. Ainsi, si le shell utilisé par l'utilisateur sur la machine distante est bash et que vous avez besoin de définir des variables d'environnements avant le lancement de la commande passée en argument à rsh, il faudra alors les placer dans le fichier ~/.bashrc.
Une remarque, pour des raisons de sécurités, il serait préférable d'utiliser ssh.
merci d'avance
De rien.
-- TiChou
Dans le message <news:c8c771$ghj$1@news-reader1.wanadoo.fr>,
*ste* tapota sur f.c.o.l.configuration :
Salut à tous,
Bonjour,
juste un petit probleme :
Quand j'essaye de me logguer avec un "rsh" sur une machine distante , tout
se passe bien a une exception pret, le rsh ne semble pas lire mon
$HOME/.profile de cette meme machine distante
pourquoi ??
ex: rsh machineB -l test "echo $<une var. definie sur l'autre machine dans
/home/test/.profile>"
C'est un « problème » de shell, pas un problème du fonctionnement de rsh.
Prenons l'exemple du shell bash. Quand celui-ci est lancé comme un shell de
login, il lira dans l'ordre les fichiers /etc/profile, ~/.bash_profile,
~/.bash_login et ~/.profile s'ils existent bien sûr.
Quand bash est lancé comme un shell interactif, c'est le cas avec la
commande 'rsh -l user host commande', il ne lira que le fichier ~/.bashrc.
Ainsi, si le shell utilisé par l'utilisateur sur la machine distante est
bash et que vous avez besoin de définir des variables d'environnements avant
le lancement de la commande passée en argument à rsh, il faudra alors les
placer dans le fichier ~/.bashrc.
Une remarque, pour des raisons de sécurités, il serait préférable d'utiliser
ssh.
Dans le message <news:c8c771$ghj$, *ste* tapota sur f.c.o.l.configuration :
Salut à tous,
Bonjour,
juste un petit probleme : Quand j'essaye de me logguer avec un "rsh" sur une machine distante , tout se passe bien a une exception pret, le rsh ne semble pas lire mon $HOME/.profile de cette meme machine distante pourquoi ??
ex: rsh machineB -l test "echo $<une var. definie sur l'autre machine dans /home/test/.profile>"
C'est un « problème » de shell, pas un problème du fonctionnement de rsh. Prenons l'exemple du shell bash. Quand celui-ci est lancé comme un shell de login, il lira dans l'ordre les fichiers /etc/profile, ~/.bash_profile, ~/.bash_login et ~/.profile s'ils existent bien sûr. Quand bash est lancé comme un shell interactif, c'est le cas avec la commande 'rsh -l user host commande', il ne lira que le fichier ~/.bashrc. Ainsi, si le shell utilisé par l'utilisateur sur la machine distante est bash et que vous avez besoin de définir des variables d'environnements avant le lancement de la commande passée en argument à rsh, il faudra alors les placer dans le fichier ~/.bashrc.
Une remarque, pour des raisons de sécurités, il serait préférable d'utiliser ssh.
