j'étais habitué à tcsh
parce que c'était le shell par défaut sous mac os x 10.1 et 10.2
je souhaite changer, parce que
- on m'a suffisamment dit que c'est un très mauvais shell (pour les
scripts, mais aussi en interactif, d'après ce que j'ai compris) pour que
je me décide
- depuis mac os x 10.3, ça m'oblige à aller dans le netinfo manager pour
changer le shell par défaut à chaque (ré)install (j'ai horreur de ça)
certains m'ont conseillé de passer à zsh,
mais je préférerais m'habituer à bash (puisque pour l'instant je ne
connais aucun des 2), sinon je serais tjr obligé de changer le shell par
défaut à chaque fois
tant pis si il y a des choses pour lesquelles il est moins confortable
pouvez vous m'aider un peu pour la transition, svp ? :-)
j'avais un fichier .tcshrc
j'ai essayé .bashrc --> rien
j'ai lu que l'équivalent est .profile
c'est bien ça ?
j'ai traduit
setenv PATH ~/bin:$PATH
en
PATH=~/bin:$PATH
c'est bon ?
ça a l'air, mais c'est bizarre, j'ai entendu dire qu'il fallait utiliser
la commande "export" à un moment donné (non ?)
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 ?
il y avait plein d'alias, et il y en a un que j'aimerais refaire sous
bash
mais
alias l 'ls -l'
ne marche pas
comment faut il l'écrire ?
pour l'autocompletion, tant pis pour les + de zsh, mais
est ce que bash sait simplement afficher la liste des possibilités,
comme le fait tcsh ?
(pour l'instant il veut bien compléter quand il y a juste une
possibilité, mais des qu'il y en a 2 il ne fait plus rien)
--
j'agis contre l'assistanat, je travaille dans une SCOP !
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"
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
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"
Vincent Lefevre
Dans l'article <46da7e1b$0$12985$, Nicolas George <nicolas$ é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.
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.
Dans l'article <46da7e1b$0$12985$, Nicolas George <nicolas$ é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.
Dans l'article <46da7e1b$0$12985$, Nicolas George <nicolas$ é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.
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.
Dans l'article <46da7e1b$0$12985$, Nicolas George <nicolas$ é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 Lefevre wrote in message <20070902094539$:
(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.
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:
Vincent Lefevre wrote in message <20070902094539$:
(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.
mpg
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.
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
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 !
Thomas
In article <46da7e1b$0$12985$, Nicolas George <nicolas$ wrote:
Thomas wrote in message :
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 <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 <46da7e1b$0$12985$, Nicolas George <nicolas$ wrote:
Thomas wrote in message :
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 !
Thomas
In article <46da93e3$0$16662$, Nicolas George <nicolas$ wrote:
Vincent Lefevre wrote in message <20070902094539$:
.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 !
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 !
In article <46da93e3$0$16662$, Nicolas George <nicolas$ wrote:
Vincent Lefevre wrote in message <20070902094539$:
.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 !
Nicolas George
Thomas wrote in message :
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.
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 ?
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.
Stephane Chazelas
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
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).
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).
