[troll]
Depuis mon crash de disque dur, mon xp et mort (et enterré) : vive le
pingouin !
[/troll]
Sérieusement, j'essaie de convertir ma femme, et j'aimerai qu'à son login, X
démarre tout seul.
Personnellement et pour le reste du système, je n'utilise pas xdm (ou
autres kdm...) mais je démarre (ou pas) la session graphique avec startx.
J'ai bien essayé de mettre startx dans son .login (avec ou sans le chemin
complet), mais il veut rien savoir...
Sébastien Kirche ( ) à écrit ce Lundi 12 Janvier 2004 10:50 sur le forum fr.comp.os.linux.configuration dans :
J'aime bien l'idée, mais ça marche pô :^( Rien, nada. Comme pour le .login, la modif du .profile ne fait rien.
Je vais rajouter des echos pour voir si la commande ne fait rien, ou si le fichier n'est peut-être même pas chargé.
J'ai eu le problème, le fichier n'est apparement pas chargé. J'ai modifié les .bash_profile de chaque utilisateurs avec ça à la fin du fichier:
if [ -f ~/.bash_login ]; then . ~/.bash_login fi
et le bash_login fonctionne à présent, si t'en crées un !
-- Web Dreamer Linux Registered User #313652 at http://counter.li.org/ Remplacer nospam par tiscali pour répondre. Replace nospam by tiscali to answer.
Sébastien Kirche ( sebastien.kirche.no@spam.free.fr.invalid ) à écrit ce
Lundi 12 Janvier 2004 10:50 sur le forum fr.comp.os.linux.configuration
dans <m2r7y5fqbr.fsf@free.fr> :
J'aime bien l'idée, mais ça marche pô :^(
Rien, nada.
Comme pour le .login, la modif du .profile ne fait rien.
Je vais rajouter des echos pour voir si la commande ne fait rien, ou si
le fichier n'est peut-être même pas chargé.
J'ai eu le problème, le fichier n'est apparement pas chargé.
J'ai modifié les .bash_profile de chaque utilisateurs avec ça à la fin du
fichier:
if [ -f ~/.bash_login ]; then
. ~/.bash_login
fi
et le bash_login fonctionne à présent, si t'en crées un !
--
Web Dreamer
Linux Registered User #313652 at http://counter.li.org/
Remplacer nospam par tiscali pour répondre.
Replace nospam by tiscali to answer.
Sébastien Kirche ( ) à écrit ce Lundi 12 Janvier 2004 10:50 sur le forum fr.comp.os.linux.configuration dans :
J'aime bien l'idée, mais ça marche pô :^( Rien, nada. Comme pour le .login, la modif du .profile ne fait rien.
Je vais rajouter des echos pour voir si la commande ne fait rien, ou si le fichier n'est peut-être même pas chargé.
J'ai eu le problème, le fichier n'est apparement pas chargé. J'ai modifié les .bash_profile de chaque utilisateurs avec ça à la fin du fichier:
if [ -f ~/.bash_login ]; then . ~/.bash_login fi
et le bash_login fonctionne à présent, si t'en crées un !
-- Web Dreamer Linux Registered User #313652 at http://counter.li.org/ Remplacer nospam par tiscali pour répondre. Replace nospam by tiscali to answer.
Cem
J'ai bien essayé de mettre startx dans son .login (avec ou sans le chemin complet), mais il veut rien savoir...
.login? Avec bash, il me semble que le fichier personnel exécuté au login doit se nommer .profile ou .bash_profile
A voir les sources de "bash", si le login shell est lancé sous le nom "sh", on exécute .profile, sinon on exécute .bash_profile et/ou .bash_login, ou .profile si aucun des des deux précédents n'existe.
J'ai bien essayé de mettre startx dans son .login (avec ou sans le chemin
complet), mais il veut rien savoir...
.login?
Avec bash, il me semble que le fichier personnel exécuté au
login doit se nommer .profile ou .bash_profile
A voir les sources de "bash", si le login shell est lancé sous le nom
"sh", on exécute .profile, sinon on exécute .bash_profile et/ou
.bash_login, ou .profile si aucun des des deux précédents n'existe.
J'ai bien essayé de mettre startx dans son .login (avec ou sans le chemin complet), mais il veut rien savoir...
.login? Avec bash, il me semble que le fichier personnel exécuté au login doit se nommer .profile ou .bash_profile
A voir les sources de "bash", si le login shell est lancé sous le nom "sh", on exécute .profile, sinon on exécute .bash_profile et/ou .bash_login, ou .profile si aucun des des deux précédents n'existe.
Rakotomandimby
Sébastien Kirche wrote:
Mais si cette contrainte n'est pas importante , alors on peut demarrer X des son login . et c'est toi qui eventuellement reviendra en mode console apre le *DM dans tes logins a toi .
Comment ? Essaie de compléter ton explication, pour mon édification et me convaincre, parce que je suis pas sûr d'adhérer :^)
Quand tu es sous X , entre dans une console et tapes "init 3" tu retournera en "runlevel 3" ( j'ai pas verifié si il faut ete root ou pas )
si tu est en console , pour entrer dans X tu as 2 solutions : -entrer "init 4" ( en tant que root ) ça te mettra un *DM -tu te logge en tant que TOI et tu ente startx .( et pour en sortir , tu fais "init 3" )
sinon : oui, runlevel 4 = "runlevel 3" + X sans plus. -- http://mrakotom.free.fr
Sébastien Kirche wrote:
Mais si cette contrainte n'est pas importante , alors on peut demarrer
X des son login . et c'est toi qui eventuellement reviendra en mode
console apre le *DM dans tes logins a toi .
Comment ?
Essaie de compléter ton explication, pour mon édification et me
convaincre, parce que je suis pas sûr d'adhérer :^)
Quand tu es sous X , entre dans une console et tapes "init 3" tu retournera
en "runlevel 3" ( j'ai pas verifié si il faut ete root ou pas )
si tu est en console , pour entrer dans X tu as 2 solutions :
-entrer "init 4" ( en tant que root ) ça te mettra un *DM
-tu te logge en tant que TOI et tu ente startx .( et pour en sortir , tu
fais "init 3" )
sinon : oui, runlevel 4 = "runlevel 3" + X
sans plus.
--
http://mrakotom.free.fr
Mais si cette contrainte n'est pas importante , alors on peut demarrer X des son login . et c'est toi qui eventuellement reviendra en mode console apre le *DM dans tes logins a toi .
Comment ? Essaie de compléter ton explication, pour mon édification et me convaincre, parce que je suis pas sûr d'adhérer :^)
Quand tu es sous X , entre dans une console et tapes "init 3" tu retournera en "runlevel 3" ( j'ai pas verifié si il faut ete root ou pas )
si tu est en console , pour entrer dans X tu as 2 solutions : -entrer "init 4" ( en tant que root ) ça te mettra un *DM -tu te logge en tant que TOI et tu ente startx .( et pour en sortir , tu fais "init 3" )
sinon : oui, runlevel 4 = "runlevel 3" + X sans plus. -- http://mrakotom.free.fr
Rakotomandimby
wrote:
TTY=`who -m |awk '{print $2}'` if [ "$TTY" = "tty1" ] ; then startx & fi
OK ça marche , c'est tant mieux ... mais es tu conscient que c'est de la bidouille ? :-) te mettre en runlevel 4 par defaut serai plus clean ... -- http://mrakotom.free.fr
fm@nowhere.invalid wrote:
TTY=`who -m |awk '{print $2}'`
if [ "$TTY" = "tty1" ] ; then
startx &
fi
OK ça marche , c'est tant mieux ... mais es tu conscient que c'est de la
bidouille ? :-)
te mettre en runlevel 4 par defaut serai plus clean ...
--
http://mrakotom.free.fr
TTY=`who -m |awk '{print $2}'` if [ "$TTY" = "tty1" ] ; then startx & fi
OK ça marche , c'est tant mieux ... mais es tu conscient que c'est de la bidouille ? :-) te mettre en runlevel 4 par defaut serai plus clean ... -- http://mrakotom.free.fr
Sébastien Kirche
Ok, merci pour la clarification sur les runlevels. Je ne pourrai expérimenter vos différentes solutions que ce soir.
Je également suis en train de considérer l'eventualité de lancer des sessions X simultanées (à expérimenter).
Histoire que ma tendre moitié ne soit pas trop perdue avec kde, alors que moi je tourne avec windowmaker. Je sais que kde est *lourd* mais c'est dans le cas d'une session courte genre "je consulte les comptes à la banque et je quitte" alors que je suis moi-même déjà loggué et que j'ai pas forcément envie de tout quitter...
[mode troll OFF] Après tout, on a bien un système qui peut faire multi-tâches et multi-utilisateurs... ;^)
Merci des infos Sébastien Kirche
Ok, merci pour la clarification sur les runlevels.
Je ne pourrai expérimenter vos différentes solutions que ce soir.
Je également suis en train de considérer l'eventualité de lancer des
sessions X simultanées (à expérimenter).
Histoire que ma tendre moitié ne soit pas trop perdue avec kde, alors que
moi je tourne avec windowmaker.
Je sais que kde est *lourd* mais c'est dans le cas d'une session courte
genre "je consulte les comptes à la banque et je quitte" alors que je suis
moi-même déjà loggué et que j'ai pas forcément envie de tout quitter...
[mode troll OFF]
Après tout, on a bien un système qui peut faire multi-tâches et
multi-utilisateurs... ;^)
Ok, merci pour la clarification sur les runlevels. Je ne pourrai expérimenter vos différentes solutions que ce soir.
Je également suis en train de considérer l'eventualité de lancer des sessions X simultanées (à expérimenter).
Histoire que ma tendre moitié ne soit pas trop perdue avec kde, alors que moi je tourne avec windowmaker. Je sais que kde est *lourd* mais c'est dans le cas d'une session courte genre "je consulte les comptes à la banque et je quitte" alors que je suis moi-même déjà loggué et que j'ai pas forcément envie de tout quitter...
[mode troll OFF] Après tout, on a bien un système qui peut faire multi-tâches et multi-utilisateurs... ;^)
Merci des infos Sébastien Kirche
Sébastien Kirche
Heu, .login (et .logout) c'est des souvenirs de la fac avec SunOS sous Sparc. Et ça marche sur mon Mac au boulot sous Darwin (=BSD) et tcsh.
Effectivement, je n'avais pas remis ce fonctionnement en question pour Linux Debian. Je vais vérifier si ça existe.
Quand à choisir, je mettrais plutôt ça dans le .profile, parce que si on change le shell de l'utilisateur, je suppose que .bash_profile n'est plus appelé... Et si on oublie qu'on a customisé avec bash, on cherche pourquoi ça marche plus.
Sébastien Kirche
Heu, .login (et .logout) c'est des souvenirs de la fac avec SunOS sous
Sparc.
Et ça marche sur mon Mac au boulot sous Darwin (=BSD) et tcsh.
Effectivement, je n'avais pas remis ce fonctionnement en question pour
Linux Debian.
Je vais vérifier si ça existe.
Quand à choisir, je mettrais plutôt ça dans le .profile, parce que si on
change le shell de l'utilisateur, je suppose que .bash_profile n'est plus
appelé...
Et si on oublie qu'on a customisé avec bash, on cherche pourquoi ça marche
plus.
Heu, .login (et .logout) c'est des souvenirs de la fac avec SunOS sous Sparc. Et ça marche sur mon Mac au boulot sous Darwin (=BSD) et tcsh.
Effectivement, je n'avais pas remis ce fonctionnement en question pour Linux Debian. Je vais vérifier si ça existe.
Quand à choisir, je mettrais plutôt ça dans le .profile, parce que si on change le shell de l'utilisateur, je suppose que .bash_profile n'est plus appelé... Et si on oublie qu'on a customisé avec bash, on cherche pourquoi ça marche plus.
Sébastien Kirche
Cem
Personnellement j'ai mis ça dans mon .bashrc à la maison (en plus d'un autologin dans inittab) :
TTY=`who -m |awk '{print $2}'` if [ "$TTY" = "tty1" ] ; then startx & fi
qui ne lance startx automatiquement que lorsque je me connecte sur la console tty1.
.bashrc n'est pas le meilleur endroit pour mettre cette commande.
Il vaut mieux le mettre dans .bash_profile afin que le startx ne soit fait que sur les seuls bash de login. Sinon, le simple fait de lancer un nouveau shell va tenter de lancer un nouveau X. Il faudrait peut-être aussi tester par précaution que X n'est pas encore lancé. Soit TTY=`who -m |awk '{print $2}'` if [ "$TTY" = "tty1" ] ; then if [ "`pidof X`" == "" ]; then startx & fi fi
Personnellement j'ai mis ça dans mon .bashrc à la maison
(en plus d'un autologin dans inittab) :
TTY=`who -m |awk '{print $2}'`
if [ "$TTY" = "tty1" ] ; then
startx &
fi
qui ne lance startx automatiquement que lorsque je me connecte
sur la console tty1.
.bashrc n'est pas le meilleur endroit pour mettre cette commande.
Il vaut mieux le mettre dans .bash_profile afin que le startx ne soit
fait que sur les seuls bash de login.
Sinon, le simple fait de lancer un nouveau shell va tenter de lancer un
nouveau X.
Il faudrait peut-être aussi tester par précaution que X n'est pas encore
lancé.
Soit
TTY=`who -m |awk '{print $2}'`
if [ "$TTY" = "tty1" ] ; then
if [ "`pidof X`" == "" ]; then
startx &
fi
fi
Personnellement j'ai mis ça dans mon .bashrc à la maison (en plus d'un autologin dans inittab) :
TTY=`who -m |awk '{print $2}'` if [ "$TTY" = "tty1" ] ; then startx & fi
qui ne lance startx automatiquement que lorsque je me connecte sur la console tty1.
.bashrc n'est pas le meilleur endroit pour mettre cette commande.
Il vaut mieux le mettre dans .bash_profile afin que le startx ne soit fait que sur les seuls bash de login. Sinon, le simple fait de lancer un nouveau shell va tenter de lancer un nouveau X. Il faudrait peut-être aussi tester par précaution que X n'est pas encore lancé. Soit TTY=`who -m |awk '{print $2}'` if [ "$TTY" = "tty1" ] ; then if [ "`pidof X`" == "" ]; then startx & fi fi
Cem
Heu, .login (et .logout) c'est des souvenirs de la fac avec SunOS sous Sparc. Et ça marche sur mon Mac au boulot sous Darwin (=BSD) et tcsh.
Effectivement, je n'avais pas remis ce fonctionnement en question pour Linux Debian. Je vais vérifier si ça existe.
Quand à choisir, je mettrais plutôt ça dans le .profile, parce que si on change le shell de l'utilisateur, je suppose que .bash_profile n'est plus appelé... Et si on oublie qu'on a customisé avec bash, on cherche pourquoi ça marche plus.
Les nom des fichiers d'initialisation dépendent malheureusement du shell utilisé. tcsh utilise effectivement .login. Pas sûr qu'utiliser .profile soit une solution vraiment universelle. Ça ne fonctionnera pas par exemple avec tcsh. Par contre c'est bon pour tous les shells compatibles sh.
Heu, .login (et .logout) c'est des souvenirs de la fac avec SunOS sous
Sparc.
Et ça marche sur mon Mac au boulot sous Darwin (=BSD) et tcsh.
Effectivement, je n'avais pas remis ce fonctionnement en question pour
Linux Debian.
Je vais vérifier si ça existe.
Quand à choisir, je mettrais plutôt ça dans le .profile, parce que si on
change le shell de l'utilisateur, je suppose que .bash_profile n'est plus
appelé...
Et si on oublie qu'on a customisé avec bash, on cherche pourquoi ça marche
plus.
Les nom des fichiers d'initialisation dépendent malheureusement du shell
utilisé.
tcsh utilise effectivement .login.
Pas sûr qu'utiliser .profile soit une solution vraiment universelle. Ça
ne fonctionnera pas par exemple avec tcsh.
Par contre c'est bon pour tous les shells compatibles sh.
Heu, .login (et .logout) c'est des souvenirs de la fac avec SunOS sous Sparc. Et ça marche sur mon Mac au boulot sous Darwin (=BSD) et tcsh.
Effectivement, je n'avais pas remis ce fonctionnement en question pour Linux Debian. Je vais vérifier si ça existe.
Quand à choisir, je mettrais plutôt ça dans le .profile, parce que si on change le shell de l'utilisateur, je suppose que .bash_profile n'est plus appelé... Et si on oublie qu'on a customisé avec bash, on cherche pourquoi ça marche plus.
Les nom des fichiers d'initialisation dépendent malheureusement du shell utilisé. tcsh utilise effectivement .login. Pas sûr qu'utiliser .profile soit une solution vraiment universelle. Ça ne fonctionnera pas par exemple avec tcsh. Par contre c'est bon pour tous les shells compatibles sh.
Sébastien Kirche
On 12 Jan 2004, Cem wrote:
[...]
Les nom des fichiers d'initialisation dépendent malheureusement du shell utilisé.
Ah ok, c'était donc ça...
tcsh utilise effectivement .login. Pas sûr qu'utiliser .profile soit une solution vraiment universelle. Ça ne fonctionnera pas par exemple avec tcsh. Par contre c'est bon pour tous les shells compatibles sh.
Ok, merci de la précision. Ça doit donc fonctionner pour bash.
[brève de comptoir] C'est quand même étonnant de voir qu'après le nième shell, après sh, ash, csh, tcsh, zsh, bash, ... et j'en oublie il n'y a encore pas de méthode qui marche dans tous les cas pour initialiser des choses au démarrage/login.
Faut toujours bricoler d'une façon ou d'une autre...
Après tout, même MSDOS avait sont autoexec.bat :^) [/brève de comptoir]
Sébastien Kirche
On 12 Jan 2004, Cem wrote:
[...]
Les nom des fichiers d'initialisation dépendent malheureusement du shell
utilisé.
Ah ok, c'était donc ça...
tcsh utilise effectivement .login.
Pas sûr qu'utiliser .profile soit une solution vraiment universelle. Ça
ne fonctionnera pas par exemple avec tcsh.
Par contre c'est bon pour tous les shells compatibles sh.
Ok, merci de la précision. Ça doit donc fonctionner pour bash.
[brève de comptoir]
C'est quand même étonnant de voir qu'après le nième shell, après sh, ash,
csh, tcsh, zsh, bash, ... et j'en oublie il n'y a encore pas de méthode qui
marche dans tous les cas pour initialiser des choses au démarrage/login.
Faut toujours bricoler d'une façon ou d'une autre...
Après tout, même MSDOS avait sont autoexec.bat :^)
[/brève de comptoir]
Les nom des fichiers d'initialisation dépendent malheureusement du shell utilisé.
Ah ok, c'était donc ça...
tcsh utilise effectivement .login. Pas sûr qu'utiliser .profile soit une solution vraiment universelle. Ça ne fonctionnera pas par exemple avec tcsh. Par contre c'est bon pour tous les shells compatibles sh.
Ok, merci de la précision. Ça doit donc fonctionner pour bash.
[brève de comptoir] C'est quand même étonnant de voir qu'après le nième shell, après sh, ash, csh, tcsh, zsh, bash, ... et j'en oublie il n'y a encore pas de méthode qui marche dans tous les cas pour initialiser des choses au démarrage/login.
Faut toujours bricoler d'une façon ou d'une autre...
Après tout, même MSDOS avait sont autoexec.bat :^) [/brève de comptoir]
Sébastien Kirche
TiChou
Dans l'article news:, Sébastien Kirche écrivait :
Une solution serait de mettre dans un des fichiers profiles de l'utilisateur (~/.bash_profile, ~/.bash_login ou ~/.profile) le petit script suivant :
Non testé, mais l'idée est là. Si l'ouverture du shell a été invoqué par login, lancer la session X en vérifiant qu'aucune session X n'est déjà lancée.
J'aime bien l'idée, mais ça marche pô :^( Rien, nada.
Au temps pour moi. Il est fort probable que le shell ne soit pas invoqué directement par /bin/login et que donc la variable $0 ne corresponde pas à ce que j'avais imaginé.
L'idée de fm est sans doute plus judicieuse, tester si le terminal ouvert est une console, que de tester la façon dont a été invoqué le shell.
Question que je me suis posé, vu que jusqu'à présent il n'existait pas de .profile ou .login : 1) est que le fichier doit être exécutable ? ke dirais non au vu du .bashrc
Non, celui-ci doit juste être lisible.
2) faut il ajouter un entête type #/bin/bash ?
Non, inutile.
Je vous invite à lire le man de bash ou de zsh, en particulier la partie INVOCATION.
-- TiChou
Dans l'article news:m2r7y5fqbr.fsf@free.fr,
Sébastien Kirche <sebastien.kirche.no@spam.free.fr.invalid> écrivait :
Une solution serait de mettre dans un des fichiers
profiles de l'utilisateur (~/.bash_profile, ~/.bash_login ou
~/.profile) le petit script suivant :
Non testé, mais l'idée est là. Si l'ouverture du shell a été invoqué
par login, lancer la session X en vérifiant qu'aucune session X
n'est déjà lancée.
J'aime bien l'idée, mais ça marche pô :^(
Rien, nada.
Au temps pour moi.
Il est fort probable que le shell ne soit pas invoqué directement par
/bin/login et que donc la variable $0 ne corresponde pas à ce que j'avais
imaginé.
L'idée de fm est sans doute plus judicieuse, tester si le terminal ouvert
est une console, que de tester la façon dont a été invoqué le shell.
Question que je me suis posé, vu que jusqu'à présent il n'existait
pas de .profile ou .login :
1) est que le fichier doit être exécutable ? ke dirais non au vu du
.bashrc
Non, celui-ci doit juste être lisible.
2) faut il ajouter un entête type #/bin/bash ?
Non, inutile.
Je vous invite à lire le man de bash ou de zsh, en particulier la partie
INVOCATION.
Non testé, mais l'idée est là. Si l'ouverture du shell a été invoqué par login, lancer la session X en vérifiant qu'aucune session X n'est déjà lancée.
J'aime bien l'idée, mais ça marche pô :^( Rien, nada.
Au temps pour moi. Il est fort probable que le shell ne soit pas invoqué directement par /bin/login et que donc la variable $0 ne corresponde pas à ce que j'avais imaginé.
L'idée de fm est sans doute plus judicieuse, tester si le terminal ouvert est une console, que de tester la façon dont a été invoqué le shell.
Question que je me suis posé, vu que jusqu'à présent il n'existait pas de .profile ou .login : 1) est que le fichier doit être exécutable ? ke dirais non au vu du .bashrc
Non, celui-ci doit juste être lisible.
2) faut il ajouter un entête type #/bin/bash ?
Non, inutile.
Je vous invite à lire le man de bash ou de zsh, en particulier la partie INVOCATION.