bash interactif

Thomas wrote in message
<fantome.forums.tDeContes-D2B15C.02055902092007@news.proxad.net>:

j'avais un fichier .tcshrc

j'ai essayé .bashrc --> rien

j'ai lu que l'équivalent est .profile
c'est bien ça ?

Pas exactement : .profile est lu à la connexion en mode texte (et des hacks
font qu'il est parfois lu à la connexion en mode graphique), .bashrc est lu
quand on ouvre un shell interactif. Sauf qu'une connerie dans bash fait que
.bashrc n'est pas lu quand le shell interactif est aussi shell de login.

Donc dans .profile : les choses à faire une fois pour l'initialisation
(PATH, umask, etc.), et dans .bashrc : les choses qui concernent le shell
courant (alias, fonctions, etc.).

ça a l'air, mais c'est bizarre, j'ai entendu dire qu'il fallait utiliser
la commande "export" à un moment donné (non ?)

La commande export marque que la variable est à exporter dans
l'environnement. Pour PATH, c'est probablement déjà fait en amont, mais ça
ne fait pas de mal de le refaire.

dans .tcshrc, il y avait une ligne :
source /usr/share/tcsh/examples/rc

je crois que c'était pour améliorer le confort en mode interactif

est ce qu'il y a un équivalent ?

Ben comme son nom l'indique, c'est des exemples.

mais
alias l 'ls -l'
ne marche pas

comment faut il l'écrire ?

man bash
/alias

alias l="ls -l"

Dans l'article <46da7e1b$0$12985$426a34cc@news.free.fr>,
Nicolas George <nicolas$george@salle-s.org> écrit:

Pas exactement : .profile est lu à la connexion en mode texte

Par forcément: c'est ~/.bash_profile ou ~/.bash_login qui est lu si
un de ces fichiers existent.

(et des hacks font qu'il est parfois lu à la connexion en mode
graphique),

Tout dépend si le shell est de login ou pas. La page man dit:

When bash is invoked as an interactive login shell, or as a non-inter-
active shell with the --login option, it first reads and executes com-
mands from the file /etc/profile, if that file exists. After reading
that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile,
in that order, and reads and executes commands from the first one that
exists and is readable. The --noprofile option may be used when the
shell is started to inhibit this behavior.

.bashrc est lu quand on ouvre un shell interactif.

Seulement si le shell n'est pas un shell de login:

When an interactive shell that is not a login shell is started, bash
reads and executes commands from ~/.bashrc, if that file exists. This
may be inhibited by using the --norc option. The --rcfile file option
will force bash to read and execute commands from file instead of
~/.bashrc.

Sauf qu'une connerie dans bash fait que .bashrc n'est pas lu quand
le shell interactif est aussi shell de login.

C'est pour cela que mon .bash_profile contient:

[[ -f ~/.bashrc ]] && source ~/.bashrc

Par conséquent, mon .profile n'est jamais lu et toutes mes commandes se
trouvent dans le ".bashrc".

En fait, mon .bash_profile contient aussi ceci:

[[ "$PS1" ]] && exec zsh -l

i.e. quand c'est un shell de login interactif, je le remplace par zsh,
car j'utilise zsh habituellement (et c'est généralement le zsh que j'ai
installé via MacPorts). Mais je peux toujours taper "bash" depuis un
zsh pour utiliser bash quand j'en ai besoin (en général, c'est pour
faire des tests).

Donc dans .profile : les choses à faire une fois pour l'initialisation
(PATH, umask, etc.),

et qui sont héritées quand tu lances un sous-shell (ou autre processus).
Cependant, le premier shell n'est pas forcément un shell de login (e.g.
connexion par ssh).

et dans .bashrc : les choses qui concernent le shell courant (alias,
fonctions, etc.).

Mais tu as aussi besoin des alias, etc. dans un shell de login
interactif.

C'est pour ces deux raisons que mon .bash_profile et mon .bashrc
exécutent les mêmes commandes.

Je préfère le système de zsh, qui est beaucoup plus logique:

Commands are then read from $ZDOTDIR/.zshenv. If the shell is a login
shell, commands are read from /etc/zprofile and then $ZDOTDIR/.zpro-
file. Then, if the shell is interactive, commands are read from
/etc/zshrc and then $ZDOTDIR/.zshrc. Finally, if the shell is a login
shell, /etc/zlogin and $ZDOTDIR/.zlogin are read.

--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Dans l'article <46da7e1b$0$12985$426a34cc@news.free.fr>,
Nicolas George <nicolas$george@salle-s.org> écrit:

Pas exactement : .profile est lu à la connexion en mode texte

Par forcément: c'est ~/.bash_profile ou ~/.bash_login qui est lu si
un de ces fichiers existe.

(et des hacks font qu'il est parfois lu à la connexion en mode
graphique),

Tout dépend si le shell est de login ou pas. La page man dit:

When bash is invoked as an interactive login shell, or as a non-inter-
active shell with the --login option, it first reads and executes com-
mands from the file /etc/profile, if that file exists. After reading
that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile,
in that order, and reads and executes commands from the first one that
exists and is readable. The --noprofile option may be used when the
shell is started to inhibit this behavior.

.bashrc est lu quand on ouvre un shell interactif.

Seulement si le shell n'est pas un shell de login:

When an interactive shell that is not a login shell is started, bash
reads and executes commands from ~/.bashrc, if that file exists. This
may be inhibited by using the --norc option. The --rcfile file option
will force bash to read and execute commands from file instead of
~/.bashrc.

Sauf qu'une connerie dans bash fait que .bashrc n'est pas lu quand
le shell interactif est aussi shell de login.

C'est pour cela que mon .bash_profile contient:

[[ -f ~/.bashrc ]] && source ~/.bashrc

Par conséquent, mon .profile n'est jamais lu et toutes mes commandes se
trouvent dans le ".bashrc".

En fait, mon .bash_profile contient aussi ceci:

[[ "$PS1" ]] && exec zsh -l

i.e. quand c'est un shell de login interactif, je le remplace par zsh,
car j'utilise zsh habituellement (et c'est généralement le zsh que j'ai
installé via MacPorts). Mais je peux toujours taper "bash" depuis un
zsh pour utiliser bash quand j'en ai besoin (en général, c'est pour
faire des tests).

Donc dans .profile : les choses à faire une fois pour l'initialisation
(PATH, umask, etc.),

et qui sont héritées quand tu lances un sous-shell (ou autre processus).
Cependant, le premier shell n'est pas forcément un shell de login (e.g.
connexion par ssh).

et dans .bashrc : les choses qui concernent le shell courant (alias,
fonctions, etc.).

Mais tu as aussi besoin des alias, etc. dans un shell de login
interactif.

C'est pour ces deux raisons que mon .bash_profile et mon .bashrc
exécutent les mêmes commandes.

Je préfère le système de zsh, qui est beaucoup plus logique:

Commands are then read from $ZDOTDIR/.zshenv. If the shell is a login
shell, commands are read from /etc/zprofile and then $ZDOTDIR/.zpro-
file. Then, if the shell is interactive, commands are read from
/etc/zshrc and then $ZDOTDIR/.zshrc. Finally, if the shell is a login
shell, /etc/zlogin and $ZDOTDIR/.zlogin are read.

--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Vincent Lefevre wrote in message
<20070902094539$0deb@prunille.vinc17.org>:

(et des hacks font qu'il est parfois lu à la connexion en mode
graphique),
Tout dépend si le shell est de login ou pas.

Une connexion en mode graphique n'invoque normalement pas le shell de
l'utilisateur, de login ou pas de login.

.bashrc est lu quand on ouvre un shell interactif.
Seulement si le shell n'est pas un shell de login:

C'est ce que j'ai marqué plus bas.

Cependant, le premier shell n'est pas forcément un shell de login (e.g.
connexion par ssh).

Un shell interactif ouvert par ssh est un shell de login.

Mais tu as aussi besoin des alias, etc. dans un shell de login
interactif.

Oui, mais leur place est quand même dans le fichier qui définit le
comportement des shells interactifs, et pas ailleurs. Il faut se débrouiller
pour contourner la stupidité de bash pour qu'il soit lu dans tous les cas,
hélas.

C'est pour ces deux raisons que mon .bash_profile et mon .bashrc
exécutent les mêmes commandes.

Mauvais : duplication de code. Il faut que l'un source l'autre.

Je préfère le système de zsh, qui est beaucoup plus logique:

À qui le dis-tu.

Bonjour,

Le (on) dimanche 02 septembre 2007 02:05, Thomas a écrit (wrote) :

j'étais habitué à tcsh
parce que c'était le shell par défaut sous mac os x 10.1 et 10.2

Un peu HS, mais par curiosité : quel est désormais le shell par défaut sous

MacOs X ? Bash ?

Manuel.

In article <fbe9rv$2kfa$2@talisker.lacave.net>, mpg <manuel.pg@free.fr>
wrote:

Le (on) dimanche 02 septembre 2007 02:05, Thomas a écrit (wrote) :

j'étais habitué à tcsh
parce que c'était le shell par défaut sous mac os x 10.1 et 10.2

Un peu HS, mais par curiosité : quel est désormais le shell par défaut sous

MacOs X ? Bash ?

oui, c'est bash

pardon, je croyais l'avoir précisé

--
j'agis contre l'assistanat, je travaille dans une SCOP !

In article <46da7e1b$0$12985$426a34cc@news.free.fr>,
Nicolas George <nicolas$george@salle-s.org> wrote:

Thomas wrote in message
<fantome.forums.tDeContes-D2B15C.02055902092007@news.proxad.net>:

j'ai entendu dire qu'il fallait utiliser
la commande "export" à un moment donné (non ?)

La commande export marque que la variable est à exporter dans
l'environnement. Pour PATH, c'est probablement déjà fait en amont, mais ça
ne fait pas de mal de le refaire.

et la différence c'est que
elle est passée à tous les processus fils,
ou pas (auquel cas c'est une variable locale) ?

mais
alias l 'ls -l'
ne marche pas

comment faut il l'écrire ?

man bash
/alias

alias l="ls -l"

merci, ça marche :-)

(mais j'ai pas compris comment t'as déduit ça du man)


par contre, grâce au "/" du man, j'ai trouvé ça :-)

Completing
complete (TAB)
Attempt to perform completion on the text before point.
Bash
attempts completion treating the text as a variable (if
the text
begins with $), username (if the text begins with ~),
hostname
(if the text begins with @), or command (including
aliases and
functions) in turn. If none of these produces a match,
filename
completion is attempted.
possible-completions (M-?)
List the possible completions of the text before point.
insert-completions (M-*)
Insert all completions of the text before point that
would have
been generated by possible-completions.

mais j'ai besoin d'aide pour déchiffrer :
- pour compléter quand il y a une seule solution, je tape sur tab, c'est
bien ça :-)
- pour avoir la liste, je devrais taper "M-?" ? quelles touches c'est,
ça ?
- insert-completions, ça permet d'insérer toute la liste des
possibilités, d'un seul coup, comme si on les avait tapées les unes
après les autres ? :-)

--
j'agis contre l'assistanat, je travaille dans une SCOP !

In article <46da93e3$0$16662$426a74cc@news.free.fr>,
Nicolas George <nicolas$george@salle-s.org> wrote:

Vincent Lefevre wrote in message
<20070902094539$0deb@prunille.vinc17.org>:

.bashrc est lu quand on ouvre un shell interactif.
Seulement si le shell n'est pas un shell de login:

C'est ce que j'ai marqué plus bas.

Un shell interactif ouvert par ssh est un shell de login.

Mais tu as aussi besoin des alias, etc. dans un shell de login
interactif.

Oui, mais leur place est quand même dans le fichier qui définit le
comportement des shells interactifs, et pas ailleurs. Il faut se débrouiller
pour contourner la stupidité de bash pour qu'il soit lu dans tous les cas,
hélas.

merci pour vos conseils, je vais essayer d'en tirer le meilleur profit
:-)
(pas garanti que j'y arrive des la 1ere fois)


bon, est ce que pour l'instant, si je met tout dans ~/.profile ça va ?

je ne pense pas avoir l'occasion de taper "bash" dans le terminal
(parce que pour l'instant, je crois que ça sera plus simple d'utiliser
le même shell pour tout, pour pas m'embrouiller avec les possibilités
des différents shells)
par contre, je ferais des connexions par ssh, et j'utiliserais des
scripts qui commencent par "#!/bin/sh -x -"

donc, est ce que ~/.profile
- est bien lu lors d'une connexion par ssh ?
- n'est pas lu lors du lancement d'un script ?

je crois que pour l'instant ces 2 conditions sont suffisantes,
mais bien sur si vous voulez m'avertir d'un cas où je peux me retrouver
dans la m... par inattention, vos contributions sont les bienvenues :-)

C'est pour ces deux raisons que mon .bash_profile et mon .bashrc
exécutent les mêmes commandes.

Mauvais : duplication de code. Il faut que l'un source l'autre.

c'est ce qu'il a fait, il l'avait écrit pus haut ;-)

Je préfère le système de zsh, qui est beaucoup plus logique:

À qui le dis-tu.

à moi, je crois ;-)

je vais y penser,
mais c'est curieux,
autant j'ai bcp entendu dire que tcsh c'est de la pourriture,
autant pour bash j'ai entendu dire que c'est pas forcément très
ergonomique, mais assez fiable quand même
non ?

--
j'agis contre l'assistanat, je travaille dans une SCOP !

Thomas wrote in message
<fantome.forums.tDeContes-C65B42.19442002092007@news.proxad.net>:

bon, est ce que pour l'instant, si je met tout dans ~/.profile ça va ?

Non, pas du tout. Ce ne sera pas exécuté pour les shells qui sont lancés
dans un émulateur de terminal graphique, par exemple.

par contre, je ferais des connexions par ssh, et j'utiliserais des
scripts qui commencent par "#!/bin/sh -x -"

Si c'est du bash, c'est #!/bin/bash qu'il faut écrire.

donc, est ce que ~/.profile
- est bien lu lors d'une connexion par ssh ?
- n'est pas lu lors du lancement d'un script ?

Oui, de ce point de vue, c'est bon.

2007-09-02, 19:44(+02), Thomas:
[...]

donc, est ce que ~/.profile
- est bien lu lors d'une connexion par ssh ?

Dans

ssh host

il est lu.

Dans

ssh host cmd

il ne l'est pas (mais ~/.bashrc l'est, un autre comportement
inattendu de bash).

- n'est pas lu lors du lancement d'un script ?
[...]

Ni ~/.profile (~/.bash_profile/login...) ni ~/.bashrc ne sont lu
par les shells qui interpretent les scripts (sauf si on passe
l'opion -l, comme dans #! /opt/bin/bash -l).

Voir la variable d'environnement BASH_ENV pour avoir un fichier
lu par tous les bashs (sauf quand ils sont lancés en tant que
sh).

--
Stéphane