J'ai une sid à jour sur un portable, mais une petite chose m'intrigue:
Le .profile est lu en console ( CTRL + ALT + F1, par exemple ) mais pas
sous X ( xfce4 ).
Je m'en suis rendu compte car les binaires dans $HOME/bin sont
"lançables" en console mais pas depuis un terminal sous xfce.
Sous wheezy en revanche, je n’ai pas ce phénomène.
Je ne sais pas qui est censé sourcer .profile quand on ouvre une session X.
Personne. Il y a des fichiers d'initialisation dédiés pour les sessions X11. Le fichier .profile est destiné aux logins texte, par définition.
Ben, quand je mets une définition de PATH dans .profile, puis que je fais "echo $PATH" dans un xterm dans ma session graphique, je récupère ce que j'ai mis dans .profile, pourtant le shell dans le xterm n'est pas un shell de login.
Dans l'exemple que j'ai donné (SLiM) il y a bien lancement d'un shell de login, lequel exécute le window manager. J'ai jeté un œil à la config de lightdm, il utilise /etc/X11/xdm/Xsession qui semble bien lancer aussi un shell de login.
Pour les usines à gaz gdm et kdm, je ne sais pas.
Pour être syntaxiquement correct, effectivement peut-être que personne n'est censé le faire, mais en pratique c'est fait, et je me demandais s'il y avait un usage.
-- LL Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης) C'est mieux avé les accents (F. Patte)
Le 28 mars 2015, Nicolas George a écrit :
Lucas Levrel , dans le message
<alpine.LNX.2.11.1503281058400.1889@localhost>, a écrit :
Je ne sais pas qui est censé sourcer .profile quand on ouvre une session
X.
Personne. Il y a des fichiers d'initialisation dédiés pour les sessions X11.
Le fichier .profile est destiné aux logins texte, par définition.
Ben, quand je mets une définition de PATH dans .profile, puis que je fais
"echo $PATH" dans un xterm dans ma session graphique, je récupère ce que
j'ai mis dans .profile, pourtant le shell dans le xterm n'est pas un shell
de login.
Dans l'exemple que j'ai donné (SLiM) il y a bien lancement d'un shell de
login, lequel exécute le window manager. J'ai jeté un œil à la config de
lightdm, il utilise /etc/X11/xdm/Xsession qui semble bien lancer aussi un
shell de login.
Pour les usines à gaz gdm et kdm, je ne sais pas.
Pour être syntaxiquement correct, effectivement peut-être que personne
n'est censé le faire, mais en pratique c'est fait, et je me demandais s'il
y avait un usage.
--
LL
Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης)
C'est mieux avé les accents (F. Patte)
Je ne sais pas qui est censé sourcer .profile quand on ouvre une session X.
Personne. Il y a des fichiers d'initialisation dédiés pour les sessions X11. Le fichier .profile est destiné aux logins texte, par définition.
Ben, quand je mets une définition de PATH dans .profile, puis que je fais "echo $PATH" dans un xterm dans ma session graphique, je récupère ce que j'ai mis dans .profile, pourtant le shell dans le xterm n'est pas un shell de login.
Dans l'exemple que j'ai donné (SLiM) il y a bien lancement d'un shell de login, lequel exécute le window manager. J'ai jeté un œil à la config de lightdm, il utilise /etc/X11/xdm/Xsession qui semble bien lancer aussi un shell de login.
Pour les usines à gaz gdm et kdm, je ne sais pas.
Pour être syntaxiquement correct, effectivement peut-être que personne n'est censé le faire, mais en pratique c'est fait, et je me demandais s'il y avait un usage.
-- LL Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης) C'est mieux avé les accents (F. Patte)
Nicolas George
Lucas Levrel , dans le message , a écrit :
Ben, quand je mets une définition de PATH dans .profile, puis que je fais "echo $PATH" dans un xterm dans ma session graphique, je récupère ce que j'ai mis dans .profile, pourtant le shell dans le xterm n'est pas un shell de login.
Beaucoup de systèmes de fichiers de config par défaut font une bouillie infâme pour faire en sorte que la config des boulets qui mettent n'importe quoi dans n'importe quel fichier de config marche quand même.
Si tu veux comprendre quoi que ce soit à ce qui se passe et avoir une chance que les choses soient fiables (par rapport à l'environnement des commandes lancées par cron, par ssh sans shell interactif, etc.), il faut commencer par un grand ménage.
Lucas Levrel , dans le message
<alpine.LSU.2.10.1503301545480.7072@coulomb.u-pec.fr>, a écrit :
Ben, quand je mets une définition de PATH dans .profile, puis que je fais
"echo $PATH" dans un xterm dans ma session graphique, je récupère ce que
j'ai mis dans .profile, pourtant le shell dans le xterm n'est pas un shell
de login.
Beaucoup de systèmes de fichiers de config par défaut font une bouillie
infâme pour faire en sorte que la config des boulets qui mettent n'importe
quoi dans n'importe quel fichier de config marche quand même.
Si tu veux comprendre quoi que ce soit à ce qui se passe et avoir une chance
que les choses soient fiables (par rapport à l'environnement des commandes
lancées par cron, par ssh sans shell interactif, etc.), il faut commencer
par un grand ménage.
Ben, quand je mets une définition de PATH dans .profile, puis que je fais "echo $PATH" dans un xterm dans ma session graphique, je récupère ce que j'ai mis dans .profile, pourtant le shell dans le xterm n'est pas un shell de login.
Beaucoup de systèmes de fichiers de config par défaut font une bouillie infâme pour faire en sorte que la config des boulets qui mettent n'importe quoi dans n'importe quel fichier de config marche quand même.
Si tu veux comprendre quoi que ce soit à ce qui se passe et avoir une chance que les choses soient fiables (par rapport à l'environnement des commandes lancées par cron, par ssh sans shell interactif, etc.), il faut commencer par un grand ménage.
Lucas Levrel
Le 30 mars 2015, Nicolas George a écrit :
Lucas Levrel , dans le message , a écrit :
Ben, quand je mets une définition de PATH dans .profile, puis que je fais "echo $PATH" dans un xterm dans ma session graphique, je récupère ce que j'ai mis dans .profile, pourtant le shell dans le xterm n'est pas un shell de login.
Beaucoup de systèmes de fichiers de config par défaut font une bouillie infâme pour faire en sorte que la config des boulets qui mettent n'importe quoi dans n'importe quel fichier de config marche quand même.
OK. Et donc quel est l'équivalent de .profile pour une session graphique ?
-- LL Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης) C'est mieux avé les accents (F. Patte)
Le 30 mars 2015, Nicolas George a écrit :
Lucas Levrel , dans le message
<alpine.LSU.2.10.1503301545480.7072@coulomb.u-pec.fr>, a écrit :
Ben, quand je mets une définition de PATH dans .profile, puis que je fais
"echo $PATH" dans un xterm dans ma session graphique, je récupère ce que
j'ai mis dans .profile, pourtant le shell dans le xterm n'est pas un shell
de login.
Beaucoup de systèmes de fichiers de config par défaut font une bouillie
infâme pour faire en sorte que la config des boulets qui mettent n'importe
quoi dans n'importe quel fichier de config marche quand même.
OK. Et donc quel est l'équivalent de .profile pour une session graphique ?
--
LL
Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης)
C'est mieux avé les accents (F. Patte)
Ben, quand je mets une définition de PATH dans .profile, puis que je fais "echo $PATH" dans un xterm dans ma session graphique, je récupère ce que j'ai mis dans .profile, pourtant le shell dans le xterm n'est pas un shell de login.
Beaucoup de systèmes de fichiers de config par défaut font une bouillie infâme pour faire en sorte que la config des boulets qui mettent n'importe quoi dans n'importe quel fichier de config marche quand même.
OK. Et donc quel est l'équivalent de .profile pour une session graphique ?
-- LL Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης) C'est mieux avé les accents (F. Patte)
Nicolas George
Lucas Levrel , dans le message , a écrit :
OK. Et donc quel est l'équivalent de .profile pour une session graphique ?
Historiquement, .Xsession.
Actuellement, chaque display manager fait ses bêtises à sa sauce et chaque distribution rajoute ses contournements de bugs en plus.
Lucas Levrel , dans le message
<alpine.LSU.2.10.1504011159120.3533@coulomb.u-pec.fr>, a écrit :
OK. Et donc quel est l'équivalent de .profile pour une session graphique ?
Historiquement, .Xsession.
Actuellement, chaque display manager fait ses bêtises à sa sauce et chaque
distribution rajoute ses contournements de bugs en plus.
OK. Et donc quel est l'équivalent de .profile pour une session graphique ?
Historiquement, .Xsession.
Actuellement, chaque display manager fait ses bêtises à sa sauce et chaque distribution rajoute ses contournements de bugs en plus.
Nicolas George
mireero , dans le message <551bce43$0$3059$, a écrit :
La conf de mon profile (debian) établit le PATH/PS1 pour utilisateur et root.
Et hop, premier bug.
PATH, c'est une variable d'environnement qui concerne tous les programmes. Pas uniquement ceux descendant d'un shell de login, pas uniquement ceux correspondant à une session graphique, tous.
PS1, c'est une variable interne qui concerne les shells interactifs. Et encore, sa signification n'est pas la même selon le shell.
mireero , dans le message <551bce43$0$3059$426a34cc@news.free.fr>, a
écrit :
La conf de mon profile (debian) établit le PATH/PS1 pour utilisateur et
root.
Et hop, premier bug.
PATH, c'est une variable d'environnement qui concerne tous les programmes.
Pas uniquement ceux descendant d'un shell de login, pas uniquement ceux
correspondant à une session graphique, tous.
PS1, c'est une variable interne qui concerne les shells interactifs. Et
encore, sa signification n'est pas la même selon le shell.
mireero , dans le message <551bce43$0$3059$, a écrit :
La conf de mon profile (debian) établit le PATH/PS1 pour utilisateur et root.
Et hop, premier bug.
PATH, c'est une variable d'environnement qui concerne tous les programmes. Pas uniquement ceux descendant d'un shell de login, pas uniquement ceux correspondant à une session graphique, tous.
PS1, c'est une variable interne qui concerne les shells interactifs. Et encore, sa signification n'est pas la même selon le shell.
mireero
On 03/27/2015 03:42 PM, Nicolas George wrote:
Doug713705 , dans le message , a écrit :
Il faut expliquer à xfce4-terminal qu'il est un "shell de connexion".
Non, il ne faut pas. Pour plein de raisons.
Il faut mettre l'initialisation dans les bons fichiers de config.
Ca quand même, ça passe pas trop! Quand on lance une info comme celle-ci, on argumente.
La conf de mon profile (debian) établit le PATH/PS1 pour utilisateur et root. Il source le bashrc et va jeter un coup d'oeil dans /etc/profile.d/* (j'ai un bash_completion et un vte qui vérifie si c'est bash, zsh etc.)
Bref, rien de dangereux, je me loggue souvent en login shell.
Alors, le problème c'est quoi?
Cordialement,
-- mireero
On 03/27/2015 03:42 PM, Nicolas George wrote:
Doug713705 , dans le message <2v5gubx9fs.ln2@golgoth31.redatomik.org>, a
écrit :
Il faut expliquer à xfce4-terminal qu'il est un "shell de connexion".
Non, il ne faut pas. Pour plein de raisons.
Il faut mettre l'initialisation dans les bons fichiers de config.
Ca quand même, ça passe pas trop!
Quand on lance une info comme celle-ci, on argumente.
La conf de mon profile (debian) établit le PATH/PS1 pour utilisateur et
root. Il source le bashrc et va jeter un coup d'oeil dans
/etc/profile.d/* (j'ai un bash_completion et un vte qui vérifie si c'est
bash, zsh etc.)
Bref, rien de dangereux, je me loggue souvent en login shell.
Il faut expliquer à xfce4-terminal qu'il est un "shell de connexion".
Non, il ne faut pas. Pour plein de raisons.
Il faut mettre l'initialisation dans les bons fichiers de config.
Ca quand même, ça passe pas trop! Quand on lance une info comme celle-ci, on argumente.
La conf de mon profile (debian) établit le PATH/PS1 pour utilisateur et root. Il source le bashrc et va jeter un coup d'oeil dans /etc/profile.d/* (j'ai un bash_completion et un vte qui vérifie si c'est bash, zsh etc.)
Bref, rien de dangereux, je me loggue souvent en login shell.
Alors, le problème c'est quoi?
Cordialement,
-- mireero
Doug713705
Le 01-04-2015, Nicolas George nous expliquait dans fr.comp.os.linux.configuration (<551bd09b$0$3178$) :
mireero , dans le message <551bce43$0$3059$, a écrit :
La conf de mon profile (debian) établit le PATH/PS1 pour utilisateur et root.
Et hop, premier bug.
PATH, c'est une variable d'environnement qui concerne tous les programmes. Pas uniquement ceux descendant d'un shell de login, pas uniquement ceux correspondant à une session graphique, tous.
PS1, c'est une variable interne qui concerne les shells interactifs. Et encore, sa signification n'est pas la même selon le shell.
Et ? En quoi est-ce grave, dérangeant, buggogène d'avoir une variable supplémentaire définie ici ?
-- Mais l'ombre des plaisirs s'enfuit Toujours plus loin vers l'inconnu. -- H.F. Thiéfaine, La môme kaléïdoscope
Le 01-04-2015, Nicolas George nous expliquait dans
fr.comp.os.linux.configuration
(<551bd09b$0$3178$426a74cc@news.free.fr>) :
mireero , dans le message <551bce43$0$3059$426a34cc@news.free.fr>, a
écrit :
La conf de mon profile (debian) établit le PATH/PS1 pour utilisateur et
root.
Et hop, premier bug.
PATH, c'est une variable d'environnement qui concerne tous les programmes.
Pas uniquement ceux descendant d'un shell de login, pas uniquement ceux
correspondant à une session graphique, tous.
PS1, c'est une variable interne qui concerne les shells interactifs. Et
encore, sa signification n'est pas la même selon le shell.
Et ? En quoi est-ce grave, dérangeant, buggogène d'avoir une
variable supplémentaire définie ici ?
--
Mais l'ombre des plaisirs s'enfuit
Toujours plus loin vers l'inconnu.
-- H.F. Thiéfaine, La môme kaléïdoscope
Le 01-04-2015, Nicolas George nous expliquait dans fr.comp.os.linux.configuration (<551bd09b$0$3178$) :
mireero , dans le message <551bce43$0$3059$, a écrit :
La conf de mon profile (debian) établit le PATH/PS1 pour utilisateur et root.
Et hop, premier bug.
PATH, c'est une variable d'environnement qui concerne tous les programmes. Pas uniquement ceux descendant d'un shell de login, pas uniquement ceux correspondant à une session graphique, tous.
PS1, c'est une variable interne qui concerne les shells interactifs. Et encore, sa signification n'est pas la même selon le shell.
Et ? En quoi est-ce grave, dérangeant, buggogène d'avoir une variable supplémentaire définie ici ?
-- Mais l'ombre des plaisirs s'enfuit Toujours plus loin vers l'inconnu. -- H.F. Thiéfaine, La môme kaléïdoscope
Lucas Levrel
Le 1 avril 2015, mireero a écrit :
La conf de mon profile (debian) établit le PATH/PS1 pour utilisateur et root. Il source le bashrc et va jeter un coup d'oeil dans /etc/profile.d/* (j'ai un bash_completion et un vte qui vérifie si c'est bash, zsh etc.)
Bref, rien de dangereux, je me loggue souvent en login shell.
Alors, le problème c'est quoi?
Si tu comprends ce que tu fais tu n'as pas de problème. Mais sinon, en confondant profile et bashrc et en sourçant l'un dans l'autre on peut avoir des surprises : - mettre PATH=/truc:$PATH dans bashrc et tu retrouves deux fois /truc dans ton PATH ; - alias ou shopt dans profile n'a pas d'effet il me semble ; - PS1 dans profile n'a d'effet que si tu l'exportes ; - si tu changes de shell les trucs de bashrc ne sont pas forcément compatibles avec. C'est quand même plus simple de laisser bash_completion dans bashrc et de ne pas le sourcer dans profile !
Rien de dangereux à première vue, non.
-- LL Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης) C'est mieux avé les accents (F. Patte)
Le 1 avril 2015, mireero a écrit :
La conf de mon profile (debian) établit le PATH/PS1 pour utilisateur et root.
Il source le bashrc et va jeter un coup d'oeil dans /etc/profile.d/* (j'ai un
bash_completion et un vte qui vérifie si c'est bash, zsh etc.)
Bref, rien de dangereux, je me loggue souvent en login shell.
Alors, le problème c'est quoi?
Si tu comprends ce que tu fais tu n'as pas de problème. Mais sinon, en
confondant profile et bashrc et en sourçant l'un dans l'autre on peut
avoir des surprises :
- mettre PATH=/truc:$PATH dans bashrc et tu retrouves deux fois /truc dans
ton PATH ;
- alias ou shopt dans profile n'a pas d'effet il me semble ;
- PS1 dans profile n'a d'effet que si tu l'exportes ;
- si tu changes de shell les trucs de bashrc ne sont pas forcément
compatibles avec. C'est quand même plus simple de laisser
bash_completion dans bashrc et de ne pas le sourcer dans profile !
Rien de dangereux à première vue, non.
--
LL
Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης)
C'est mieux avé les accents (F. Patte)
La conf de mon profile (debian) établit le PATH/PS1 pour utilisateur et root. Il source le bashrc et va jeter un coup d'oeil dans /etc/profile.d/* (j'ai un bash_completion et un vte qui vérifie si c'est bash, zsh etc.)
Bref, rien de dangereux, je me loggue souvent en login shell.
Alors, le problème c'est quoi?
Si tu comprends ce que tu fais tu n'as pas de problème. Mais sinon, en confondant profile et bashrc et en sourçant l'un dans l'autre on peut avoir des surprises : - mettre PATH=/truc:$PATH dans bashrc et tu retrouves deux fois /truc dans ton PATH ; - alias ou shopt dans profile n'a pas d'effet il me semble ; - PS1 dans profile n'a d'effet que si tu l'exportes ; - si tu changes de shell les trucs de bashrc ne sont pas forcément compatibles avec. C'est quand même plus simple de laisser bash_completion dans bashrc et de ne pas le sourcer dans profile !
Rien de dangereux à première vue, non.
-- LL Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης) C'est mieux avé les accents (F. Patte)
Nicolas George
Doug713705 , dans le message , a écrit :
Et ? En quoi est-ce grave, dérangeant, buggogène d'avoir une variable supplémentaire définie ici ?
Pour PS1, ce n'est pas trop grave, mais si elle est exportée dans l'environnement, elle va affecter des shells qui utilisent une syntaxe différente. Problème assez mineur je te l'accorde.
Mais si on continue à faire n'importe quoi avec les fichiers d'initialisation du shell, on peut se retrouver avec des alias dans des shells non interactifs qui exécutent des scripts et ça peut dramatiquement changer leur comportement.
Doug713705 , dans le message <1f7tubx5jc.ln2@golgoth31.redatomik.org>, a
écrit :
Et ? En quoi est-ce grave, dérangeant, buggogène d'avoir une
variable supplémentaire définie ici ?
Pour PS1, ce n'est pas trop grave, mais si elle est exportée dans
l'environnement, elle va affecter des shells qui utilisent une syntaxe
différente. Problème assez mineur je te l'accorde.
Mais si on continue à faire n'importe quoi avec les fichiers
d'initialisation du shell, on peut se retrouver avec des alias dans des
shells non interactifs qui exécutent des scripts et ça peut dramatiquement
changer leur comportement.
Et ? En quoi est-ce grave, dérangeant, buggogène d'avoir une variable supplémentaire définie ici ?
Pour PS1, ce n'est pas trop grave, mais si elle est exportée dans l'environnement, elle va affecter des shells qui utilisent une syntaxe différente. Problème assez mineur je te l'accorde.
Mais si on continue à faire n'importe quoi avec les fichiers d'initialisation du shell, on peut se retrouver avec des alias dans des shells non interactifs qui exécutent des scripts et ça peut dramatiquement changer leur comportement.
Sergio
Le 01/04/2015 21:13, Nicolas George a écrit :
Mais si on continue à faire n'importe quoi avec les fichiers d'initialisation du shell, on peut se retrouver avec des alias dans des shells non interactifs qui exécutent des scripts et ça peut dramatiquement changer leur comportement.
Règle numéro un : Les alias ne sont *jamais* interprétés dans les scripts (sauf bien sûr ceux définis dans le script...).
-- Serge http://leserged.online.fr/ Mon blog: http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
Le 01/04/2015 21:13, Nicolas George a écrit :
Mais si on continue à faire n'importe quoi avec les fichiers
d'initialisation du shell, on peut se retrouver avec des alias dans des
shells non interactifs qui exécutent des scripts et ça peut dramatiquement
changer leur comportement.
Règle numéro un : Les alias ne sont *jamais* interprétés dans les scripts (sauf bien sûr ceux définis dans le script...).
--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org
Mais si on continue à faire n'importe quoi avec les fichiers d'initialisation du shell, on peut se retrouver avec des alias dans des shells non interactifs qui exécutent des scripts et ça peut dramatiquement changer leur comportement.
Règle numéro un : Les alias ne sont *jamais* interprétés dans les scripts (sauf bien sûr ceux définis dans le script...).
-- Serge http://leserged.online.fr/ Mon blog: http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
