il y a longtemps, je me suis emmerdé à changer le shell de login sur un
certain nb d'ordinateurs, parce qu'il y avait bash par défaut et que je
ne connaissais que tcsh, et je ne savais pas quoi faire d'autre
maintenant, j'ai pris l'habitude de bash sur mon ordi perso, et
j'aimerais l'avoir "à nouveau" sur les ordis distants
mais si il suffit de mettre qqch dans ~/.tcshrc pour simuler un shell de
login, j'aimerais éviter les mêmes complications à l'envers :-)
est ce que c'est possible de simuler le fait d'avoir bash comme shell de
login juste en mettant qqch dans ~/.tcshrc ?
(terminal, ssh interactif, ssh commande, ^D, déconnexion réseau, ...
je ne sais pas tout ce qu'il y a comme possibilités, mais j'aimerais
qu'il y ait le moins de différences possibles entre la simulation depuis
tcsh et ce que ça serait si je remettais bash comme shell de login)
est ce qu'il suffit de mettre
/bin/bash -l
?
ou
/bin/bash -l -
?
ou il faut d'autres options ? ou c'est plus compliqué ?
est ce que bash est appelé avec -l du moment qu'il est le shell de
login, ou seulement avec ssh mais pas quand on lance le terminal, par
exemple ?
j'ai essayé de lire le chapitre INVOCATION mais j'ai pas tout compris ...
est ce que qqn peut m'éclaircir les choses, svp ? :-)
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
Vincent Lefevre
Dans l'article , Thomas écrit:
est ce que c'est possible de simuler le fait d'avoir bash comme shell de login juste en mettant qqch dans ~/.tcshrc ?
Oui. En ce qui me concerne, j'ai dans mon .cshrc, après la mise en place des variables d'environnment:
if ($?ZSH) then if (-x $ZSH) then setenv SHELL $ZSH if ($?loginsh) set ZSH = "$ZSH -l" if ($?prompt) echo "executing $ZSH" exec shexec $ZSH endif endif
Le shexec est:
#!/usr/bin/env perl
# Workaround for the tcsh exec bug. Example: # tcsh> exec shexec zsh
use strict;
eval { require POSIX; foreach (3..63) { POSIX::close $_ if -t $_ } 1; } or warn <<"EOF"; Perl POSIX module not found! The non-standard file descriptors attached to a tty (as those let open by this buggy tcsh) could not be closed. EOF
Dans l'article <fantome.forums.tDeContes-2EA3A8.04131221092008@news.free.fr>,
Thomas <fantome.forums.tDeContes@free.fr.invalid> écrit:
est ce que c'est possible de simuler le fait d'avoir bash comme shell de
login juste en mettant qqch dans ~/.tcshrc ?
Oui. En ce qui me concerne, j'ai dans mon .cshrc, après la mise en
place des variables d'environnment:
if ($?ZSH) then
if (-x $ZSH) then
setenv SHELL $ZSH
if ($?loginsh) set ZSH = "$ZSH -l"
if ($?prompt) echo "executing $ZSH"
exec shexec $ZSH
endif
endif
Le shexec est:
#!/usr/bin/env perl
# Workaround for the tcsh exec bug. Example:
# tcsh> exec shexec zsh
use strict;
eval {
require POSIX;
foreach (3..63)
{ POSIX::close $_ if -t $_ }
1;
} or warn <<"EOF";
Perl POSIX module not found! The non-standard file descriptors attached
to a tty (as those let open by this buggy tcsh) could not be closed.
EOF
est ce que c'est possible de simuler le fait d'avoir bash comme shell de login juste en mettant qqch dans ~/.tcshrc ?
Oui. En ce qui me concerne, j'ai dans mon .cshrc, après la mise en place des variables d'environnment:
if ($?ZSH) then if (-x $ZSH) then setenv SHELL $ZSH if ($?loginsh) set ZSH = "$ZSH -l" if ($?prompt) echo "executing $ZSH" exec shexec $ZSH endif endif
Le shexec est:
#!/usr/bin/env perl
# Workaround for the tcsh exec bug. Example: # tcsh> exec shexec zsh
use strict;
eval { require POSIX; foreach (3..63) { POSIX::close $_ if -t $_ } 1; } or warn <<"EOF"; Perl POSIX module not found! The non-standard file descriptors attached to a tty (as those let open by this buggy tcsh) could not be closed. EOF
In article <20080921193406$, Vincent Lefevre <vincent+ wrote:
Dans l'article , Thomas écrit:
> est ce que c'est possible de simuler le fait d'avoir bash comme shell de > login juste en mettant qqch dans ~/.tcshrc ?
Oui. En ce qui me concerne, j'ai dans mon .cshrc, après la mise en place des variables d'environnment:
if ($?ZSH) then if (-x $ZSH) then
j'ai pas trouvé ce que fait -x à cet endroit, c'est important ? (j'ai cherché dans http://pwet.fr/man/linux/commandes/tcsh , c'est à jour ?)
setenv SHELL $ZSH if ($?loginsh) set ZSH = "$ZSH -l" if ($?prompt) echo "executing $ZSH" exec shexec $ZSH endif endif
bon en fait tu t'es fait une préparation dans $ZSH, et un script pour l'analyser, j'ai pas besoin de tout ça,
en squeezant shexec,
if ($?loginsh) then bash -l else bash endif
me suffit ?
mais j'ai pas compris ce que shexec fait, donc je ne sais pas ce que je rate :
Le shexec est:
#!/usr/bin/env perl
# Workaround for the tcsh exec bug. Example: # tcsh> exec shexec zsh
use strict;
eval { require POSIX; foreach (3..63) { POSIX::close $_ if -t $_ } 1; } or warn <<"EOF"; Perl POSIX module not found! The non-standard file descriptors attached to a tty (as those let open by this buggy tcsh) could not be closed. EOF
exec @ARGV;
peux tu m'expliquer en gros, que je sache si c'est très important ou pas, stp ?
In article <20080921193406$4481@prunille.vinc17.org>,
Vincent Lefevre <vincent+news@vinc17.org> wrote:
Dans l'article <fantome.forums.tDeContes-2EA3A8.04131221092008@news.free.fr>,
Thomas <fantome.forums.tDeContes@free.fr.invalid> écrit:
> est ce que c'est possible de simuler le fait d'avoir bash comme shell de
> login juste en mettant qqch dans ~/.tcshrc ?
Oui. En ce qui me concerne, j'ai dans mon .cshrc, après la mise en
place des variables d'environnment:
if ($?ZSH) then
if (-x $ZSH) then
j'ai pas trouvé ce que fait -x à cet endroit, c'est important ?
(j'ai cherché dans http://pwet.fr/man/linux/commandes/tcsh , c'est à
jour ?)
setenv SHELL $ZSH
if ($?loginsh) set ZSH = "$ZSH -l"
if ($?prompt) echo "executing $ZSH"
exec shexec $ZSH
endif
endif
bon en fait tu t'es fait une préparation dans $ZSH, et un script pour
l'analyser, j'ai pas besoin de tout ça,
en squeezant shexec,
if ($?loginsh) then
bash -l
else
bash
endif
me suffit ?
mais j'ai pas compris ce que shexec fait, donc je ne sais pas ce que je
rate :
Le shexec est:
#!/usr/bin/env perl
# Workaround for the tcsh exec bug. Example:
# tcsh> exec shexec zsh
use strict;
eval {
require POSIX;
foreach (3..63)
{ POSIX::close $_ if -t $_ }
1;
} or warn <<"EOF";
Perl POSIX module not found! The non-standard file descriptors attached
to a tty (as those let open by this buggy tcsh) could not be closed.
EOF
exec @ARGV;
peux tu m'expliquer en gros, que je sache si c'est très important ou
pas, stp ?
In article <20080921193406$, Vincent Lefevre <vincent+ wrote:
Dans l'article , Thomas écrit:
> est ce que c'est possible de simuler le fait d'avoir bash comme shell de > login juste en mettant qqch dans ~/.tcshrc ?
Oui. En ce qui me concerne, j'ai dans mon .cshrc, après la mise en place des variables d'environnment:
if ($?ZSH) then if (-x $ZSH) then
j'ai pas trouvé ce que fait -x à cet endroit, c'est important ? (j'ai cherché dans http://pwet.fr/man/linux/commandes/tcsh , c'est à jour ?)
setenv SHELL $ZSH if ($?loginsh) set ZSH = "$ZSH -l" if ($?prompt) echo "executing $ZSH" exec shexec $ZSH endif endif
bon en fait tu t'es fait une préparation dans $ZSH, et un script pour l'analyser, j'ai pas besoin de tout ça,
en squeezant shexec,
if ($?loginsh) then bash -l else bash endif
me suffit ?
mais j'ai pas compris ce que shexec fait, donc je ne sais pas ce que je rate :
Le shexec est:
#!/usr/bin/env perl
# Workaround for the tcsh exec bug. Example: # tcsh> exec shexec zsh
use strict;
eval { require POSIX; foreach (3..63) { POSIX::close $_ if -t $_ } 1; } or warn <<"EOF"; Perl POSIX module not found! The non-standard file descriptors attached to a tty (as those let open by this buggy tcsh) could not be closed. EOF
exec @ARGV;
peux tu m'expliquer en gros, que je sache si c'est très important ou pas, stp ?
Le (on) lundi 22 septembre 2008 17:30, Thomas a écrit (wrote) :
if ($?ZSH) then if (-x $ZSH) then
j'ai pas trouvé ce que fait -x à cet endroit, c'est important ? (j'ai cherché dans http://pwet.fr/man/linux/commandes/tcsh , c'est à jour ?)
Je ne connais pas tcsh, mais si ça ressemble au moins un peu à ce que je connais, ça teste si $ZSH pointe vers un exécutable.
if ($?loginsh) then bash -l else bash endif
me suffit ?
Bah tu auras toujours ton tcsh qui tourne derrière. en particulier, tu devras faire deux fois "logout" pour te déloguer. Il me semble que c'est le exec qui évite ça.
peux tu m'expliquer en gros, que je sache si c'est très important ou pas, stp ?
Visiblement, tcsh fait partie des shells qui proposent des file descriptor supplémentaires au-delà des trois qui sont standard : 0 (stdin), 1 (stdout) et 2 (stderr) ; et le exec de base de tcsh ne les ferme pas proprement, ce que répare le script shexec.
Manuel.
PS : sur ton problème de base, j'avoue ne pas trop comprendre pourquoi tu ne souhaites pas changer "proprement" (avec chsh ou tout autre mécanisme équivalent proposé sur la machine en question) : si c'est juste parce que c'est compliqué, il me semble que la solution de contournement n'est guère plus simple.
Personnellement, pour le seul compte que j'ai où l'admin ne m'autorise pas à changer mon shell de login, j'utilise les deux trucs suivants : dans ~/bin, j'ai un wrapper qui lance l'émulateur de terminal X avec -e zsh, et à la maison un alias qui lance ssh -t '/path/to/zsh -l' pour me connecter audit compte. Ça répond bien à mes besoins.
Le (on) lundi 22 septembre 2008 17:30, Thomas a écrit (wrote) :
if ($?ZSH) then
if (-x $ZSH) then
j'ai pas trouvé ce que fait -x à cet endroit, c'est important ?
(j'ai cherché dans http://pwet.fr/man/linux/commandes/tcsh , c'est à
jour ?)
Je ne connais pas tcsh, mais si ça ressemble au moins un peu à ce que je
connais, ça teste si $ZSH pointe vers un exécutable.
if ($?loginsh) then
bash -l
else
bash
endif
me suffit ?
Bah tu auras toujours ton tcsh qui tourne derrière. en particulier, tu
devras faire deux fois "logout" pour te déloguer. Il me semble que c'est le
exec qui évite ça.
peux tu m'expliquer en gros, que je sache si c'est très important ou
pas, stp ?
Visiblement, tcsh fait partie des shells qui proposent des file descriptor
supplémentaires au-delà des trois qui sont standard : 0 (stdin), 1 (stdout)
et 2 (stderr) ; et le exec de base de tcsh ne les ferme pas proprement, ce
que répare le script shexec.
Manuel.
PS : sur ton problème de base, j'avoue ne pas trop comprendre pourquoi tu ne
souhaites pas changer "proprement" (avec chsh ou tout autre mécanisme
équivalent proposé sur la machine en question) : si c'est juste parce que
c'est compliqué, il me semble que la solution de contournement n'est guère
plus simple.
Personnellement, pour le seul compte que j'ai où l'admin ne m'autorise pas à
changer mon shell de login, j'utilise les deux trucs suivants : dans ~/bin,
j'ai un wrapper qui lance l'émulateur de terminal X avec -e zsh, et à la
maison un alias qui lance ssh -t '/path/to/zsh -l' pour me connecter audit
compte. Ça répond bien à mes besoins.
Le (on) lundi 22 septembre 2008 17:30, Thomas a écrit (wrote) :
if ($?ZSH) then if (-x $ZSH) then
j'ai pas trouvé ce que fait -x à cet endroit, c'est important ? (j'ai cherché dans http://pwet.fr/man/linux/commandes/tcsh , c'est à jour ?)
Je ne connais pas tcsh, mais si ça ressemble au moins un peu à ce que je connais, ça teste si $ZSH pointe vers un exécutable.
if ($?loginsh) then bash -l else bash endif
me suffit ?
Bah tu auras toujours ton tcsh qui tourne derrière. en particulier, tu devras faire deux fois "logout" pour te déloguer. Il me semble que c'est le exec qui évite ça.
peux tu m'expliquer en gros, que je sache si c'est très important ou pas, stp ?
Visiblement, tcsh fait partie des shells qui proposent des file descriptor supplémentaires au-delà des trois qui sont standard : 0 (stdin), 1 (stdout) et 2 (stderr) ; et le exec de base de tcsh ne les ferme pas proprement, ce que répare le script shexec.
Manuel.
PS : sur ton problème de base, j'avoue ne pas trop comprendre pourquoi tu ne souhaites pas changer "proprement" (avec chsh ou tout autre mécanisme équivalent proposé sur la machine en question) : si c'est juste parce que c'est compliqué, il me semble que la solution de contournement n'est guère plus simple.
Personnellement, pour le seul compte que j'ai où l'admin ne m'autorise pas à changer mon shell de login, j'utilise les deux trucs suivants : dans ~/bin, j'ai un wrapper qui lance l'émulateur de terminal X avec -e zsh, et à la maison un alias qui lance ssh -t '/path/to/zsh -l' pour me connecter audit compte. Ça répond bien à mes besoins.
Thomas
In article <gb8fgk$1p5a$, mpg wrote:
Le (on) lundi 22 septembre 2008 17:30, Thomas a écrit (wrote) :
>> if ($?ZSH) then >> if (-x $ZSH) then > > j'ai pas trouvé ce que fait -x à cet endroit, c'est important ? > (j'ai cherché dans http://pwet.fr/man/linux/commandes/tcsh , c'est à > jour ?) > Je ne connais pas tcsh, mais si ça ressemble au moins un peu à ce que je connais, ça teste si $ZSH pointe vers un exécutable.
ok donc pas besoin
> if ($?loginsh) then > bash -l > else > bash > endif > > me suffit ? > Bah tu auras toujours ton tcsh qui tourne derrière. en particulier, tu devras faire deux fois "logout" pour te déloguer. Il me semble que c'est le exec qui évite ça.
ah oui, exec recouvre tcsh sans faire de fork
> peux tu m'expliquer en gros, que je sache si c'est très important ou > pas, stp ? > Visiblement, tcsh fait partie des shells qui proposent des file descriptor supplémentaires au-delà des trois qui sont standard : 0 (stdin), 1 (stdout) et 2 (stderr)
(mais c'est pas le système qui gère les file descriptor ? ou alors tous les processus peuvent en avoir autant qu'ils veulent ?? je ne me souvenais pas de ça)
et le exec de base de tcsh ne les ferme pas proprement, ce que répare le script shexec.
merci :-)
donc si j'ai bien suivi, je peux faire bash -l exit au lieu de exec shexec bash -l
l'inconvénient, c'est que tcsh reste en arrière plan (est ce que c'est très gênant ?) l'avantage, c'est qu'il garde ses pbs de file descriptor supplémentaires pour lui
c'est bien ça ? :-)
Manuel.
PS : sur ton problème de base, j'avoue ne pas trop comprendre pourquoi tu ne souhaites pas changer "proprement" (avec chsh ou tout autre mécanisme équivalent proposé sur la machine en question)
oh mince !! c'est super simple (bon heureusement que j'ai appris vi des mon entrée à la fac :-D ) et ça marche ! :-))
quand j'ai changé le shell de login dans le 1er sens, on m'a dit qu'il fallait passer par le gestionnaire net info, - en ligne de commande j'ai trop peur de me tromper - en passant par vnc - il faut taper le mdp 2 fois - c'est pas facile avec le clavier qui tape pas tous les caractères correctement - si je fais pas attention à quelle heure je le fais, qqn pouvait arriver à tout moment ...
si c'est juste parce que c'est compliqué, il me semble que la solution de contournement n'est guère plus simple.
une fois la bonne formule trouvée, j'ai un client sftp graphique pour la coller en quelques clics sur tous les ordis que je gère
In article <gb8fgk$1p5a$1@talisker.lacave.net>, mpg <mpg@elzevir.fr>
wrote:
Le (on) lundi 22 septembre 2008 17:30, Thomas a écrit (wrote) :
>> if ($?ZSH) then
>> if (-x $ZSH) then
>
> j'ai pas trouvé ce que fait -x à cet endroit, c'est important ?
> (j'ai cherché dans http://pwet.fr/man/linux/commandes/tcsh , c'est à
> jour ?)
>
Je ne connais pas tcsh, mais si ça ressemble au moins un peu à ce que je
connais, ça teste si $ZSH pointe vers un exécutable.
ok donc pas besoin
> if ($?loginsh) then
> bash -l
> else
> bash
> endif
>
> me suffit ?
>
Bah tu auras toujours ton tcsh qui tourne derrière. en particulier, tu
devras faire deux fois "logout" pour te déloguer. Il me semble que c'est le
exec qui évite ça.
ah oui, exec recouvre tcsh sans faire de fork
> peux tu m'expliquer en gros, que je sache si c'est très important ou
> pas, stp ?
>
Visiblement, tcsh fait partie des shells qui proposent des file descriptor
supplémentaires au-delà des trois qui sont standard : 0 (stdin), 1 (stdout)
et 2 (stderr)
(mais c'est pas le système qui gère les file descriptor ? ou alors tous
les processus peuvent en avoir autant qu'ils veulent ?? je ne me
souvenais pas de ça)
et le exec de base de tcsh ne les ferme pas proprement, ce
que répare le script shexec.
merci :-)
donc si j'ai bien suivi, je peux faire
bash -l
exit
au lieu de
exec shexec bash -l
l'inconvénient, c'est que tcsh reste en arrière plan (est ce que c'est
très gênant ?)
l'avantage, c'est qu'il garde ses pbs de file descriptor supplémentaires
pour lui
c'est bien ça ? :-)
Manuel.
PS : sur ton problème de base, j'avoue ne pas trop comprendre pourquoi tu ne
souhaites pas changer "proprement" (avec chsh ou tout autre mécanisme
équivalent proposé sur la machine en question)
oh mince !!
c'est super simple
(bon heureusement que j'ai appris vi des mon entrée à la fac :-D )
et ça marche ! :-))
quand j'ai changé le shell de login dans le 1er sens, on m'a dit qu'il
fallait passer par le gestionnaire net info,
- en ligne de commande
j'ai trop peur de me tromper
- en passant par vnc
- il faut taper le mdp 2 fois
- c'est pas facile avec le clavier qui tape pas tous les caractères
correctement
- si je fais pas attention à quelle heure je le fais, qqn pouvait
arriver à tout moment
...
si c'est juste parce que
c'est compliqué, il me semble que la solution de contournement n'est guère
plus simple.
une fois la bonne formule trouvée, j'ai un client sftp graphique pour la
coller en quelques clics sur tous les ordis que je gère
Le (on) lundi 22 septembre 2008 17:30, Thomas a écrit (wrote) :
>> if ($?ZSH) then >> if (-x $ZSH) then > > j'ai pas trouvé ce que fait -x à cet endroit, c'est important ? > (j'ai cherché dans http://pwet.fr/man/linux/commandes/tcsh , c'est à > jour ?) > Je ne connais pas tcsh, mais si ça ressemble au moins un peu à ce que je connais, ça teste si $ZSH pointe vers un exécutable.
ok donc pas besoin
> if ($?loginsh) then > bash -l > else > bash > endif > > me suffit ? > Bah tu auras toujours ton tcsh qui tourne derrière. en particulier, tu devras faire deux fois "logout" pour te déloguer. Il me semble que c'est le exec qui évite ça.
ah oui, exec recouvre tcsh sans faire de fork
> peux tu m'expliquer en gros, que je sache si c'est très important ou > pas, stp ? > Visiblement, tcsh fait partie des shells qui proposent des file descriptor supplémentaires au-delà des trois qui sont standard : 0 (stdin), 1 (stdout) et 2 (stderr)
(mais c'est pas le système qui gère les file descriptor ? ou alors tous les processus peuvent en avoir autant qu'ils veulent ?? je ne me souvenais pas de ça)
et le exec de base de tcsh ne les ferme pas proprement, ce que répare le script shexec.
merci :-)
donc si j'ai bien suivi, je peux faire bash -l exit au lieu de exec shexec bash -l
l'inconvénient, c'est que tcsh reste en arrière plan (est ce que c'est très gênant ?) l'avantage, c'est qu'il garde ses pbs de file descriptor supplémentaires pour lui
c'est bien ça ? :-)
Manuel.
PS : sur ton problème de base, j'avoue ne pas trop comprendre pourquoi tu ne souhaites pas changer "proprement" (avec chsh ou tout autre mécanisme équivalent proposé sur la machine en question)
oh mince !! c'est super simple (bon heureusement que j'ai appris vi des mon entrée à la fac :-D ) et ça marche ! :-))
quand j'ai changé le shell de login dans le 1er sens, on m'a dit qu'il fallait passer par le gestionnaire net info, - en ligne de commande j'ai trop peur de me tromper - en passant par vnc - il faut taper le mdp 2 fois - c'est pas facile avec le clavier qui tape pas tous les caractères correctement - si je fais pas attention à quelle heure je le fais, qqn pouvait arriver à tout moment ...
si c'est juste parce que c'est compliqué, il me semble que la solution de contournement n'est guère plus simple.
une fois la bonne formule trouvée, j'ai un client sftp graphique pour la coller en quelques clics sur tous les ordis que je gère
Personnellement, moi je suis sous une base d'authentification NIS et lorsque je souhaite changer le shell de login par défaut je fais un : ypchsh
Arnaud Gomes-do-Vale
poulacou writes:
Personnellement, moi je suis sous une base d'authentification NIS et lorsque je souhaite changer le shell de login par défaut je fais un : ypchsh
C'est un très bon moyen de casser des trucs avec un parc hétérogène.
Ici, pendant pas mal de temps, on a eu un seul shell qui existait et qui se comportait (à peu près) pareil sur toutes nos plate-formes, c'était /bin/csh. Du coup c'était (et c'est d'ailleurs toujours) le shell de login de tout le monde, et hors de question d'en changer.
-- Arnaud
poulacou <poulacou@gmail.com> writes:
Personnellement, moi je suis sous une base d'authentification NIS
et lorsque je souhaite changer le shell de login par défaut je fais
un : ypchsh
C'est un très bon moyen de casser des trucs avec un parc hétérogène.
Ici, pendant pas mal de temps, on a eu un seul shell qui existait et
qui se comportait (à peu près) pareil sur toutes nos plate-formes,
c'était /bin/csh. Du coup c'était (et c'est d'ailleurs toujours) le
shell de login de tout le monde, et hors de question d'en changer.
Personnellement, moi je suis sous une base d'authentification NIS et lorsque je souhaite changer le shell de login par défaut je fais un : ypchsh
C'est un très bon moyen de casser des trucs avec un parc hétérogène.
Ici, pendant pas mal de temps, on a eu un seul shell qui existait et qui se comportait (à peu près) pareil sur toutes nos plate-formes, c'était /bin/csh. Du coup c'était (et c'est d'ailleurs toujours) le shell de login de tout le monde, et hors de question d'en changer.
-- Arnaud
Vincent Lefevre
Dans l'article <gb8fgk$1p5a$, mpg écrit:
> peux tu m'expliquer en gros, que je sache si c'est très important ou > pas, stp ? > Visiblement, tcsh fait partie des shells qui proposent des file descriptor supplémentaires au-delà des trois qui sont standard : 0 (stdin), 1 (stdout) et 2 (stderr) ;
Non, tout processus se voit attribuer des file descriptors lorsqu'il ouvre des fichiers (la commande "ulimit -n" donne le nombre maximal de file descriptors qui peuvent être ouverts).
et le exec de base de tcsh ne les ferme pas proprement, ce que répare le script shexec.
Le problème est que tcsh semble dupliquer les trois fd standard, et on se retrouve typiquement avec 6 fd attachés au terminal: 0, 1, 2, 3, 4 et 5. Pour se détacher du terminal, on redirige habituellement les 3 fd standard. Mais à cause du bug de tcsh, les fd 3, 4 et 5 sont toujours ouverts et attachés au terminal.
La conséquence est que si on lance un processus en arrière plan (e.g. un processus de calcul), il héritera de ces 3 fd non standard attachés au terminal, si bien que si on termine le shell et que ce processus tourne encore, ssh ne rendra pas la main, car il attend (via sshd) que tous les processus tournant encore se détachent du terminal.
Le wrapper shexec permet de pouvoir lancer normalement des processus en arrière-plan (ceux-ci faisant le nécessaire pour rediriger les fd standard ou alors l'utilisateur se sert d'une commande du style nohup qui fait ce travail) et d'obtenir la main quand on quitte le shell distant.
Dans l'article <gb8fgk$1p5a$1@talisker.lacave.net>,
mpg <mpg@elzevir.fr> écrit:
> peux tu m'expliquer en gros, que je sache si c'est très important ou
> pas, stp ?
>
Visiblement, tcsh fait partie des shells qui proposent des file descriptor
supplémentaires au-delà des trois qui sont standard : 0 (stdin), 1 (stdout)
et 2 (stderr) ;
Non, tout processus se voit attribuer des file descriptors lorsqu'il
ouvre des fichiers (la commande "ulimit -n" donne le nombre maximal
de file descriptors qui peuvent être ouverts).
et le exec de base de tcsh ne les ferme pas proprement, ce
que répare le script shexec.
Le problème est que tcsh semble dupliquer les trois fd standard, et
on se retrouve typiquement avec 6 fd attachés au terminal: 0, 1, 2,
3, 4 et 5. Pour se détacher du terminal, on redirige habituellement
les 3 fd standard. Mais à cause du bug de tcsh, les fd 3, 4 et 5
sont toujours ouverts et attachés au terminal.
La conséquence est que si on lance un processus en arrière plan (e.g.
un processus de calcul), il héritera de ces 3 fd non standard attachés
au terminal, si bien que si on termine le shell et que ce processus
tourne encore, ssh ne rendra pas la main, car il attend (via sshd) que
tous les processus tournant encore se détachent du terminal.
Le wrapper shexec permet de pouvoir lancer normalement des processus
en arrière-plan (ceux-ci faisant le nécessaire pour rediriger les fd
standard ou alors l'utilisateur se sert d'une commande du style nohup
qui fait ce travail) et d'obtenir la main quand on quitte le shell
distant.
> peux tu m'expliquer en gros, que je sache si c'est très important ou > pas, stp ? > Visiblement, tcsh fait partie des shells qui proposent des file descriptor supplémentaires au-delà des trois qui sont standard : 0 (stdin), 1 (stdout) et 2 (stderr) ;
Non, tout processus se voit attribuer des file descriptors lorsqu'il ouvre des fichiers (la commande "ulimit -n" donne le nombre maximal de file descriptors qui peuvent être ouverts).
et le exec de base de tcsh ne les ferme pas proprement, ce que répare le script shexec.
Le problème est que tcsh semble dupliquer les trois fd standard, et on se retrouve typiquement avec 6 fd attachés au terminal: 0, 1, 2, 3, 4 et 5. Pour se détacher du terminal, on redirige habituellement les 3 fd standard. Mais à cause du bug de tcsh, les fd 3, 4 et 5 sont toujours ouverts et attachés au terminal.
La conséquence est que si on lance un processus en arrière plan (e.g. un processus de calcul), il héritera de ces 3 fd non standard attachés au terminal, si bien que si on termine le shell et que ce processus tourne encore, ssh ne rendra pas la main, car il attend (via sshd) que tous les processus tournant encore se détachent du terminal.
Le wrapper shexec permet de pouvoir lancer normalement des processus en arrière-plan (ceux-ci faisant le nécessaire pour rediriger les fd standard ou alors l'utilisateur se sert d'une commande du style nohup qui fait ce travail) et d'obtenir la main quand on quitte le shell distant.
Vincent Lefevre wrote in message <20080928232514$:
Le problème est que tcsh semble dupliquer les trois fd standard, et on se retrouve typiquement avec 6 fd attachés au terminal: 0, 1, 2, 3, 4 et 5. Pour se détacher du terminal, on redirige habituellement les 3 fd standard. Mais à cause du bug de tcsh, les fd 3, 4 et 5 sont toujours ouverts et attachés au terminal.
Attention, « attaché au terminal » a un sens assez standard et très précis sous Unix : ça désigne le fait, pour un processus, d'avoir ce terminal pour terminal de contrôle, ce qui implique, en particulier, de pouvoir recevoir des signaux en provenance de ce terminal. C'est une propriété du processus qui n'a rien à voir avec les file descriptors qu'il peut avoir.
Vincent Lefevre wrote in message
<20080928232514$7d79@prunille.vinc17.org>:
Le problème est que tcsh semble dupliquer les trois fd standard, et
on se retrouve typiquement avec 6 fd attachés au terminal: 0, 1, 2,
3, 4 et 5. Pour se détacher du terminal, on redirige habituellement
les 3 fd standard. Mais à cause du bug de tcsh, les fd 3, 4 et 5
sont toujours ouverts et attachés au terminal.
Attention, « attaché au terminal » a un sens assez standard et très précis
sous Unix : ça désigne le fait, pour un processus, d'avoir ce terminal pour
terminal de contrôle, ce qui implique, en particulier, de pouvoir recevoir
des signaux en provenance de ce terminal. C'est une propriété du processus
qui n'a rien à voir avec les file descriptors qu'il peut avoir.
Vincent Lefevre wrote in message <20080928232514$:
Le problème est que tcsh semble dupliquer les trois fd standard, et on se retrouve typiquement avec 6 fd attachés au terminal: 0, 1, 2, 3, 4 et 5. Pour se détacher du terminal, on redirige habituellement les 3 fd standard. Mais à cause du bug de tcsh, les fd 3, 4 et 5 sont toujours ouverts et attachés au terminal.
Attention, « attaché au terminal » a un sens assez standard et très précis sous Unix : ça désigne le fait, pour un processus, d'avoir ce terminal pour terminal de contrôle, ce qui implique, en particulier, de pouvoir recevoir des signaux en provenance de ce terminal. C'est une propriété du processus qui n'a rien à voir avec les file descriptors qu'il peut avoir.