sid, X et ./profile

mireero <mireero@free.fr> écrivait :

On 04/02/2015 07:28 AM, Sergio wrote:

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...).

Ok, merci pour toutes les précisions, je suis rassuré et on peut dire
à l'op qu'il peut se logguer en shell de connexion sans problème alors
(en passant, s'il a besoin on ajoute un tiret après su par exemple)?

1- Merci pour l'info sur les alias.

2- Les /etc/bash.bashrc et ~.bashrc sont testés en début de fichier et
ne font rien si on n'est pas intéractif.

3- Les "profile" ne sourcent bash que si PS1 n'est pas positionné et
si on est bien dans bash ($BASH non vide).
Plus précisement, chez moi seul le profile global source quelque
chose, il faut créer un ~/bashrc si on veux que le profile local le
source et j'ai un ~/bash.bashrc.
C'est logique, si on est dans ksh, on n'en a rien à faire du bashrc

Remarque:
- Mon /etc/profile me définit un alias ls='ls --color'.
- Le ~/bash.bashrc est bien sourcé quelque part car ses directives
sont bien executées mais où?

Je parle pour debian mais ça doit ressembler aux autres.

Que c'est complexe. Mais virez donc cette lmerde de bash et passez à
zsh, bien plus carré là dessus, avec toutes les features de bash et
quelques autres en plus.

Et sh pour les scripts. Ou perl/ruby/python si ça dépasse 10 lignes.

--
Les simplifications c'est trop compliqué

Le 02/04/2015 08:55, mireero a écrit :

1- Merci pour l'info sur les alias.

2- Les /etc/bash.bashrc et ~.bashrc sont testés en début de fichier et ne font rien si on n'est pas intéractif.

3- Les "profile" ne sourcent bash que si PS1 n'est pas positionné et si on est bien dans bash ($BASH non vide).
Plus précisement, chez moi seul le profile global source quelque chose, il faut créer un ~/bashrc si on veux que le profile local le
source et j'ai un ~/bash.bashrc.
C'est logique, si on est dans ksh, on n'en a rien à faire du bashrc

Remarque:
- Mon /etc/profile me définit un alias ls='ls --color'.
- Le ~/bash.bashrc est bien sourcé quelque part car ses directives sont bien executées mais où?

Les fichiers présents dans /etc/ (règle générale, pas seulement pour les shells...) sont interprétés par les applis de tous les
utilisateurs. Ceux du profil de l'utilisateur, par celles de l'utilisateur.

Donc /etc/profile est exécuté pour tous, alors que ~/.profile est exécuté pour l'utilisateur
et /etc/bash.bashrc est exécuté pour tous, et ~/.bashrc pour l'utilisateur et ce dans les même conditions.

--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org

Sergio , dans le message <551cd394$0$3335$426a74cc@news.free.fr>, a
écrit :

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...).

Et sauf ceux définis dans un fichier d'initialisation sourcé par le shell du
script. Si, si, je t'assure, vérifie, tout comme moi j'ai vérifié avant
d'affirmer.

On est vaguement sauvé par le fait que les fichiers d'initialisation sourcés
dans ce cas-là sont très restreints, mais si les gens continuent à mettre
de la config n'importe où dans tous les sens pour faire marcher des choses
sans les comprendre, ça finira par arriver.

On 04/02/2015 07:28 AM, Sergio wrote:

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...).

Ok, merci pour toutes les précisions, je suis rassuré et on peut dire à
l'op qu'il peut se logguer en shell de connexion sans problème alors (en
passant, s'il a besoin on ajoute un tiret après su par exemple)?

1- Merci pour l'info sur les alias.

2- Les /etc/bash.bashrc et ~.bashrc sont testés en début de fichier et
ne font rien si on n'est pas intéractif.

3- Les "profile" ne sourcent bash que si PS1 n'est pas positionné et si
on est bien dans bash ($BASH non vide).
Plus précisement, chez moi seul le profile global source quelque chose,
il faut créer un ~/bashrc si on veux que le profile local le source et
j'ai un ~/bash.bashrc.
C'est logique, si on est dans ksh, on n'en a rien à faire du bashrc

Remarque:
- Mon /etc/profile me définit un alias ls='ls --color'.
- Le ~/bash.bashrc est bien sourcé quelque part car ses directives sont
bien executées mais où?

Je parle pour debian mais ça doit ressembler aux autres.

Cordialement

--
mireero

mireero , dans le message <551d2915$0$3055$426a74cc@news.free.fr>, a
écrit :

Et la réponse (ça m’apprendra à lire le code en 2 2 5 min avant d'aller
bosser)
Ben tout simplement dans le ~/.profile (comme prévu je dirais).

Non, ce n'est pas ça du tout.

~/.bashrc est sourcé automatiquement par bash lui-même, sans que ce soit
indiqué dans un fichier de config.

SAUF... que bash a une misfeature idiote : il ne source pas ~/.bashrc quand
c'est un shell de login, même si c'est _aussi_ un shell interactif. Du coup
les distributions mettent des contournements : sourcer ~/.bashrc (le fichier
de config pour les shells interactifs) depuis ~/.profile (le fichier de
config pour les shells de login). Ça a quelques inconvénients,
essentiellement le risque de mal le faire et de se retrouver coincé pour
quelques cas particuliers.

Par contre, si c'est qu'une question de PATH, et que tu es sur bash,
t'as qu'à le modifier dans ~/bashrc.

Non, non et non, c'est complètement buggé, et en pratique ça a pour
conséquence de laisser orphelins les crontabs, les commandes à distances
sans shell interactif, les procmailrc, etc.

On 04/02/2015 08:35 AM, Sergio wrote:

- Le ~/bash.bashrc est bien sourcé quelque part car ses directives
sont bien executées mais où?

Les fichiers présents dans /etc/ (règle générale, pas seulement pour les
shells...) sont interprétés par les applis de tous les utilisateurs.
Ceux du profil de l'utilisateur, par celles de l'utilisateur.

Donc /etc/profile est exécuté pour tous, alors que ~/.profile est
exécuté pour l'utilisateur
et /etc/bash.bashrc est exécuté pour tous, et ~/.bashrc pour
l'utilisateur et ce dans les même conditions.

Je suis bien d'accord, étant le seul utilisateur de ma machine je ne
touche en général qu'aux fichiers dans ~.
Contre exemple, si je veux modifier le comportement de vim, je modifie
/etc/vim/vimrc.local, comme ça la prochaine fois que je modifie quelque
chose dans /etc y'aura les belles couleurs et tout (enfin, si je modifie
que ça, on a genre un serpent qui se mord la queue je crois, ou une
réaction qui précède l'action :) ).

Bref, la question devient:
Quand je suis un utilisateur (en fait c'est dur d'être autre chose,
j’admets), où est sourcé le ~/.bashrc?

Et la réponse (ça m’apprendra à lire le code en 2 2 5 min avant d'aller
bosser)
Ben tout simplement dans le ~/.profile (comme prévu je dirais).

Petite info sur debian et dérivés, c'est dash (shell minimal, efficace,
enfin il parait) qui est utilisé par les scripts automatiques (non
interactif quoi), y'a qu'à regarder "readlink /etc/bash".
Enfin, quand on a un /bin/sh en haut bien sûr.

Morale (c'est toujours la même en fait):
Ne toucher à /etc que si:
- On n'a pas d'équivalent dans ~.
- On comprend les répercutions.
*sauf*
- Quand on est chez soi.
- Et qu'on aime bien faire n'importe quoi parce que découvrir après d'où
vient tel ou tel bug, ça devient un beau challenge et là on apprend à
coup sûr ce qu'il faut pas faire et pas parce qu'on l'a lu quelque part
et qu'on l'a souvent oublié).
- Et pourquoi pas éventuellement trouver des bugs auxquels n'avait pas
pensé le développeur de tel ou tel projet.

Trop cool, je viens de prouver qu'il fallait mettre le bordel dans /etc,
je vous mets au défi d'y arriver (avec autant de classe que moi
s'entend! ;) ).

@ Nicolas:
Ok pour zsh (et le reste aussi), on dit que c'est plus efficace et que
c'est *le* shell des _linuxiens_ . Mais j'ai pas le temps de m'y mettre là.
Edit: pas troll, dac!

@ Lucas:
Compris, rien de dangereux quand on sait ce qu'on fait (j'avais peur
qu'il y ait un piège caché).

@ "autres":
Rien, mais j'apprécie votre participation (nan, c'est vrai!)

@ OP:
Perso je ne vois aucun souci à ce que tu utilises un login shell (j'en
ai 5 qui tournent de tty2 à tty6).
Par contre, si c'est qu'une question de PATH, et que tu es sur bash,
t'as qu'à le modifier dans ~/bashrc.

*Question*:
Les applications graphiques lancées depuis un gestionnaire de fenêtre
qui est lancé depuis depuis un shell (bash) de connexion (comme chez
moi, j'ai dans mon ~/.profile un:

[if [ "$(tty)" == "/dev/tty1" ]; then
startx
fi

Donc les applis graphiques héritent-elles de tout le bazar dans les
profile et bashrc ou y'a un ménage qui est fait?
Pardon pour la question, je sais qu'il est possible d'écrire un petit
programme qui affiche les variables positionnées, mais y'a les alias et
y'a ce à quoi je pense pas, donc au final je dis pas pardon, c'est une
bonne question finalement :)


Bon, le roman c'était pas prévu, désolé et à plus!

--
mireero

Le 02/04/2015 14:20, Nicolas George a écrit :

mireero , dans le message <551d2915$0$3055$426a74cc@news.free.fr>, a
écrit :

Et la réponse (ça m’apprendra à lire le code en 2 2 5 min avant d'aller
bosser)
Ben tout simplement dans le ~/.profile (comme prévu je dirais).

Non, ce n'est pas ça du tout.

~/.bashrc est sourcé automatiquement par bash lui-même, sans que ce soit
indiqué dans un fichier de config.

SAUF... que bash a une misfeature idiote : il ne source pas ~/.bashrc quand
c'est un shell de login, même si c'est _aussi_ un shell interactif. Du coup
les distributions mettent des contournements : sourcer ~/.bashrc (le fichier
de config pour les shells interactifs) depuis ~/.profile (le fichier de
config pour les shells de login). Ça a quelques inconvénients,
essentiellement le risque de mal le faire et de se retrouver coincé pour
quelques cas particuliers.

Par contre, si c'est qu'une question de PATH, et que tu es sur bash,
t'as qu'à le modifier dans ~/bashrc.

Non, non et non, c'est complètement buggé, et en pratique ça a pour
conséquence de laisser orphelins les crontabs, les commandes à distances
sans shell interactif, les procmailrc, etc.

Bon, je ne pensais pas intéresser autant.
Je reformule donc autrement ( ça peut intéresser d'autres personnes ):

J'aimerais que, dans un teminal quelconque ( xterm, etc... ) mon PATH
indique également $HOME/bin afin de pouvoir lancer aisément des scripts
persos qui y sont présent.

La question initiale était posée pour une distribution debian/sid.

Merci
Michel

Le 2 avril 2015, mireero a écrit :

*Question*:
Les applications graphiques lancées depuis un gestionnaire de fenêtre qui est
lancé depuis depuis un shell (bash) de connexion (comme chez moi, j'ai dans
mon ~/.profile un:

[if [ "$(tty)" == "/dev/tty1" ]; then
startx
fi

Donc les applis graphiques héritent-elles de tout le bazar dans les profile
et bashrc ou y'a un ménage qui est fait?
Pardon pour la question, je sais qu'il est possible d'écrire un petit
programme qui affiche les variables positionnées, mais y'a les alias et y'a
ce à quoi je pense pas, donc au final je dis pas pardon, c'est une bonne
question finalement :)

Si j'ai bien compris le man, toutes les variables exportées sont héritées.
Un petit test très simple semble montrer que les alias ne le sont pas :
taper dans un terminal sous bash

alias toto=titi
bash -c 'alias -p'

Après, les trucs auxquels tu ne penses pas, je peux pas te dire ;)

--
LL
Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης)
C'est mieux avé les accents (F. Patte)

mireero <mireero@free.fr> écrivait :

On 04/02/2015 02:20 PM, Nicolas George wrote:

mireero , dans le message <551d2915$0$3055$426a74cc@news.free.fr>, a
écrit :

Et la réponse (ça m’apprendra à lire le code en 2 2 5 min avant d'aller
bosser)
Ben tout simplement dans le ~/.profile (comme prévu je dirais).

Non, ce n'est pas ça du tout.

~/.bashrc est sourcé automatiquement par bash lui-même, sans q ue ce soit
indiqué dans un fichier de config.

SAUF... que bash a une misfeature idiote : il ne source pas ~/.bashrc qu and
c'est un shell de login, même si c'est _aussi_ un shell interactif. Du coup
les distributions mettent des contournements : sourcer ~/.bashrc (le fic hier
de config pour les shells interactifs) depuis ~/.profile (le fichier de
config pour les shells de login). Ça a quelques inconvénients,
essentiellement le risque de mal le faire et de se retrouver coincé pour
quelques cas particuliers.

Par contre, si c'est qu'une question de PATH, et que tu es sur bash,
t'as qu'à le modifier dans ~/bashrc.

Non, non et non, c'est complètement buggé, et en pratique à §a a pour
conséquence de laisser orphelins les crontabs, les commandes à distances
sans shell interactif, les procmailrc, etc.

J'aimerais comprendre ce qu'il y a de buggé dans un:
PATH=$PATH:~/bin
dans un bashrc.

QUe ça ne marche pas si toin shell est un shell de login. Parceque bash
est buggué. De conception.

--
Les simplifications c'est trop compliqué

On 04/02/2015 02:20 PM, Nicolas George wrote:

mireero , dans le message <551d2915$0$3055$426a74cc@news.free.fr>, a
écrit :

Et la réponse (ça m’apprendra à lire le code en 2 2 5 min avant d'aller
bosser)
Ben tout simplement dans le ~/.profile (comme prévu je dirais).

Non, ce n'est pas ça du tout.

~/.bashrc est sourcé automatiquement par bash lui-même, sans que ce soit
indiqué dans un fichier de config.

SAUF... que bash a une misfeature idiote : il ne source pas ~/.bashrc quand
c'est un shell de login, même si c'est _aussi_ un shell interactif. Du coup
les distributions mettent des contournements : sourcer ~/.bashrc (le fichier
de config pour les shells interactifs) depuis ~/.profile (le fichier de
config pour les shells de login). Ça a quelques inconvénients,
essentiellement le risque de mal le faire et de se retrouver coincé pour
quelques cas particuliers.

Par contre, si c'est qu'une question de PATH, et que tu es sur bash,
t'as qu'à le modifier dans ~/bashrc.

Non, non et non, c'est complètement buggé, et en pratique ça a pour
conséquence de laisser orphelins les crontabs, les commandes à distances
sans shell interactif, les procmailrc, etc.

J'aimerais comprendre ce qu'il y a de buggé dans un:
PATH=$PATH:~/bin
dans un bashrc.

--
mireero