Aujourd'hui je veux mettre de l'ordre dans mes fichiers de démarrage de
shell.
Est-ce qu'une bonne âme pourrait nous faire pour bash l'équivalent de ce
que le camarade Jayce a fait pour tcsh et zsh ?
<http://www.mosx.net/dossiers/Shell-5.shtml>
----
Les fichiers de démarrage de /bin/tcsh
Les fichiers standards de démarrage de tcsh sont:
[snip]
Dans MacOS X, il y a quelques fichiers supplémentaires.
En fait, les fichiers /etc/csh.cshrc, /etc/csh.login et
/etc/csh.logout, font appel des fichiers situés dans le dossier
/usr/share/init/tcsh/. Ces nouveaux fichiers définissent une nouvelle
hiérarchie des fichiers de démarrage.
On obtient donc, au total, les fichiers suivant (dans cet ordre de
chargement) :
/etc/csh.cshrc (*)
/usr/share/init/tcsh/rc (*)
/usr/share/init/tcsh/environment (*)
~/Library/init/tcsh/environment.mine (*)
/usr/share/init/tcsh/tcsh.defaults (*)
~/Library/init/tcsh/rc.mine (*)
/usr/share/init/tcsh/aliases (**)
~/Library/init/tcsh/aliases.mine (**)
/usr/share/init/tcsh/completions (**)
~/Library/init/tcsh/completions.mine (**)
/etc/csh.login
/usr/share/init/tcsh/login
~/Library/init/tcsh/path
~/Library/init/tcsh/login.mine
~/.tcshrc (*)
(~/.cshrc) (*)
~/.login
~/.history
~/.cshdirs
/etc/csh.logout
/usr/share/init/tcsh/logout
~/Library/init/tcsh/logout.mine
~/.logout
Lorsque le shell n'est pas un shell de login, seuls les fichiers marqués
par (*) ou (**) sont lus. Les fichiers marqués par (**) ne sont pas lus
quand le shell n'est pas un shell interactif. Mais bien sûr, comme tout
ceci est géré dans les scripts eux-mêmes, vous pouvez très bien modifier
ce comportement comme bon vous semble...
----
<http://www.mosx.net/dossiers/Shell-6.shtml#par6b>
----
Les fichiers de démarrage utilisés par zsh sont les suivants, dans
l'ordre d'utilisation :
/etc/zshenv
~/.zshenv
/etc/zprofile (*)
~/.zprofile (*)
/etc/zshrc (i)
~/.zshrc (i)
/etc/zlogin (*)
~/.zlogin (*)
/etc/zlogout (*)
~/.zlogout (*)
Si, dans /etc/zshenv l'option RCS est désactivé, tous les autres
fichiers de démarrage sont ignorés.
Les fichiers marqués d'un (*) ne sont lus que lorsque le shell est un
shell de login (cf l'article précédent).
Les fichiers marqués d'un (i) ne sont lus que lorsque le shell est un
shell interactif (où l'utilisateur peut taper des commandes).
----
--
Jacques PERROCHEAU
Synthèse et Electrosynthèse Organiques, C.N.R.S. UMR 6510
Université de Rennes I, Campus de Beaulieu, F-35042 RENNES Cedex
Tel: +33 2 23 23 63 74, Fax: +33 2 23 23 63 74
Aujourd'hui je veux mettre de l'ordre dans mes fichiers de démarrage de shell.
Est-ce qu'une bonne âme pourrait nous faire pour bash l'équivalent de ce que le camarade Jayce a fait pour tcsh et zsh ? [...]
Il n'y a pas de logique pour bash, et ca depend des versions de bash et des options de compilation et des options passees et de argv[0] de suivant s'il y a une variable SSH_CLIENT ou SSH2_CLIENT dans l'environnement (et que stdin est une socket)...
/etc/profile et ~/.bash_profile sont executés par les shells de login. ~/.bash_login est executé par les shells de login que s'il n'y a pas de ~/.bash_profile. ~/.profile est executé par les shells de login que s'il n'y a ni ~/.bash_profile ni ~/.bash_login ou que bash est en mode sh. Les fichiers dont le nom contient "bash" ne sont pas executés en mode sh.
/etc/bash.bashrc et ~/.bashrc ne sont executés (pas en mode sh) que par les shells interactifs qui ne sont pas de login ou les shells non-interactifs qui sont lancés par ssh (cherchez la logique).
$ENV est executé par bash en mode sh que s'il est interactif.
$BASH_ENV est executé par les bash non-interactifs sauf en mode sh.
Maintenant /etc/bash.bashrc n'est pas supporté par tous les bash (option de compilation).
Les options comme --rcfile, --init-file, --login, --norc, --posix, --noprofile ont aussi une influence.
C'est le comportement qu'on observe ordinairement sous la plupart des Unix. Maintenant, c'est peut-etre different sous MacOSX.
-- Stephane
2005-01-13, 11:38(+01), Jacques Perrocheau:
[...]
Aujourd'hui je veux mettre de l'ordre dans mes fichiers de démarrage de
shell.
Est-ce qu'une bonne âme pourrait nous faire pour bash l'équivalent de ce
que le camarade Jayce a fait pour tcsh et zsh ?
[...]
Il n'y a pas de logique pour bash, et ca depend des versions de
bash et des options de compilation et des options passees et de
argv[0] de suivant s'il y a une variable SSH_CLIENT ou
SSH2_CLIENT dans l'environnement (et que stdin est une socket)...
/etc/profile et ~/.bash_profile sont executés par les shells de
login. ~/.bash_login est executé par les shells de login que
s'il n'y a pas de ~/.bash_profile. ~/.profile est executé par
les shells de login que s'il n'y a ni ~/.bash_profile ni
~/.bash_login ou que bash est en mode sh.
Les fichiers dont le nom contient "bash" ne sont pas executés en
mode sh.
/etc/bash.bashrc et ~/.bashrc ne sont executés (pas en mode sh)
que par les shells interactifs qui ne sont pas de login ou les
shells non-interactifs qui sont lancés par ssh (cherchez la
logique).
$ENV est executé par bash en mode sh que s'il est interactif.
$BASH_ENV est executé par les bash non-interactifs sauf en mode
sh.
Maintenant /etc/bash.bashrc n'est pas supporté par tous les bash
(option de compilation).
Les options comme --rcfile, --init-file, --login, --norc,
--posix, --noprofile ont aussi une influence.
C'est le comportement qu'on observe ordinairement sous la
plupart des Unix. Maintenant, c'est peut-etre different sous
MacOSX.
Aujourd'hui je veux mettre de l'ordre dans mes fichiers de démarrage de shell.
Est-ce qu'une bonne âme pourrait nous faire pour bash l'équivalent de ce que le camarade Jayce a fait pour tcsh et zsh ? [...]
Il n'y a pas de logique pour bash, et ca depend des versions de bash et des options de compilation et des options passees et de argv[0] de suivant s'il y a une variable SSH_CLIENT ou SSH2_CLIENT dans l'environnement (et que stdin est une socket)...
/etc/profile et ~/.bash_profile sont executés par les shells de login. ~/.bash_login est executé par les shells de login que s'il n'y a pas de ~/.bash_profile. ~/.profile est executé par les shells de login que s'il n'y a ni ~/.bash_profile ni ~/.bash_login ou que bash est en mode sh. Les fichiers dont le nom contient "bash" ne sont pas executés en mode sh.
/etc/bash.bashrc et ~/.bashrc ne sont executés (pas en mode sh) que par les shells interactifs qui ne sont pas de login ou les shells non-interactifs qui sont lancés par ssh (cherchez la logique).
$ENV est executé par bash en mode sh que s'il est interactif.
$BASH_ENV est executé par les bash non-interactifs sauf en mode sh.
Maintenant /etc/bash.bashrc n'est pas supporté par tous les bash (option de compilation).
Les options comme --rcfile, --init-file, --login, --norc, --posix, --noprofile ont aussi une influence.
C'est le comportement qu'on observe ordinairement sous la plupart des Unix. Maintenant, c'est peut-etre different sous MacOSX.
-- Stephane
Grrrr
On Thu, 13 Jan 2005 11:10:35 +0000, Stephane Chazelas wrote:
2005-01-13, 11:38(+01), Jacques Perrocheau: [...]
Aujourd'hui je veux mettre de l'ordre dans mes fichiers de démarrage de shell.
Est-ce qu'une bonne âme pourrait nous faire pour bash l'équivalent de ce que le camarade Jayce a fait pour tcsh et zsh ? [...]
Il n'y a pas de logique pour bash, et ca depend des versions de bash et des options de compilation et des options passees et de argv[0] de suivant s'il y a une variable SSH_CLIENT ou SSH2_CLIENT dans l'environnement (et que stdin est une socket)... [...]
/etc/bash.bashrc et ~/.bashrc ne sont executés (pas en mode sh) que par les shells interactifs qui ne sont pas de login ou les shells non-interactifs qui sont lancés par ssh (cherchez la logique).
La logique est, je crois, que: ssh <somewhere> <commande> fait exactement la même chose que: ssh <somewhere> # <commande> # exit Pour que ça marche à tous les coups, il faut bien avoir le même environnement...
[...]
On Thu, 13 Jan 2005 11:10:35 +0000, Stephane Chazelas wrote:
2005-01-13, 11:38(+01), Jacques Perrocheau:
[...]
Aujourd'hui je veux mettre de l'ordre dans mes fichiers de démarrage de
shell.
Est-ce qu'une bonne âme pourrait nous faire pour bash l'équivalent de ce
que le camarade Jayce a fait pour tcsh et zsh ?
[...]
Il n'y a pas de logique pour bash, et ca depend des versions de
bash et des options de compilation et des options passees et de
argv[0] de suivant s'il y a une variable SSH_CLIENT ou
SSH2_CLIENT dans l'environnement (et que stdin est une socket)...
[...]
/etc/bash.bashrc et ~/.bashrc ne sont executés (pas en mode sh)
que par les shells interactifs qui ne sont pas de login ou les
shells non-interactifs qui sont lancés par ssh (cherchez la
logique).
La logique est, je crois, que:
ssh <somewhere> <commande>
fait exactement la même chose que:
ssh <somewhere>
# <commande>
# exit
Pour que ça marche à tous les coups, il faut bien avoir le même
environnement...
On Thu, 13 Jan 2005 11:10:35 +0000, Stephane Chazelas wrote:
2005-01-13, 11:38(+01), Jacques Perrocheau: [...]
Aujourd'hui je veux mettre de l'ordre dans mes fichiers de démarrage de shell.
Est-ce qu'une bonne âme pourrait nous faire pour bash l'équivalent de ce que le camarade Jayce a fait pour tcsh et zsh ? [...]
Il n'y a pas de logique pour bash, et ca depend des versions de bash et des options de compilation et des options passees et de argv[0] de suivant s'il y a une variable SSH_CLIENT ou SSH2_CLIENT dans l'environnement (et que stdin est une socket)... [...]
/etc/bash.bashrc et ~/.bashrc ne sont executés (pas en mode sh) que par les shells interactifs qui ne sont pas de login ou les shells non-interactifs qui sont lancés par ssh (cherchez la logique).
La logique est, je crois, que: ssh <somewhere> <commande> fait exactement la même chose que: ssh <somewhere> # <commande> # exit Pour que ça marche à tous les coups, il faut bien avoir le même environnement...
[...]
Stephane Chazelas
2005-01-13, 13:00(+01), Grrrr: [...]
/etc/bash.bashrc et ~/.bashrc ne sont executés (pas en mode sh) que par les shells interactifs qui ne sont pas de login ou les shells non-interactifs qui sont lancés par ssh (cherchez la logique).
La logique est, je crois, que: ssh <somewhere> <commande> fait exactement la même chose que: ssh <somewhere> # <commande> # exit Pour que ça marche à tous les coups, il faut bien avoir le même environnement... [...]
Ben non, justement
ssh <somewhere> # <commande>
ca lance un shell de login qui lit ~/.profile et pas ~/.bashrc.
~/.<program>rc est le fichier de customization du <program> en general... sauf pour bash.
Note que les scripts shells lancés par ssh lisent le .bashrc (et donc les fonctions utilisateurs et tous les trucs qui sont censés n'etre activé que pour les shells interactifs) ce qui peut poser de gros problemes. csh a ce genre de probleme mais il est moins pernicieux car tous les shells lisent le ~/.cshrc, donc on met #! /bin/csh -f dans les scripts. Pour bash, il faudrait mettre #! /bin/bash --norc pour le cas ou le script pourrait etre executé par ssh.
-- Stephane
2005-01-13, 13:00(+01), Grrrr:
[...]
/etc/bash.bashrc et ~/.bashrc ne sont executés (pas en mode sh)
que par les shells interactifs qui ne sont pas de login ou les
shells non-interactifs qui sont lancés par ssh (cherchez la
logique).
La logique est, je crois, que:
ssh <somewhere> <commande>
fait exactement la même chose que:
ssh <somewhere>
# <commande>
# exit
Pour que ça marche à tous les coups, il faut bien avoir le même
environnement...
[...]
Ben non, justement
ssh <somewhere>
# <commande>
ca lance un shell de login qui lit ~/.profile et pas ~/.bashrc.
~/.<program>rc est le fichier de customization du <program> en
general... sauf pour bash.
Note que les scripts shells lancés par ssh lisent le .bashrc (et
donc les fonctions utilisateurs et tous les trucs qui sont
censés n'etre activé que pour les shells interactifs) ce qui
peut poser de gros problemes. csh a ce genre de probleme mais il
est moins pernicieux car tous les shells lisent le ~/.cshrc,
donc on met #! /bin/csh -f dans les scripts. Pour bash, il
faudrait mettre #! /bin/bash --norc pour le cas ou le script
pourrait etre executé par ssh.
/etc/bash.bashrc et ~/.bashrc ne sont executés (pas en mode sh) que par les shells interactifs qui ne sont pas de login ou les shells non-interactifs qui sont lancés par ssh (cherchez la logique).
La logique est, je crois, que: ssh <somewhere> <commande> fait exactement la même chose que: ssh <somewhere> # <commande> # exit Pour que ça marche à tous les coups, il faut bien avoir le même environnement... [...]
Ben non, justement
ssh <somewhere> # <commande>
ca lance un shell de login qui lit ~/.profile et pas ~/.bashrc.
~/.<program>rc est le fichier de customization du <program> en general... sauf pour bash.
Note que les scripts shells lancés par ssh lisent le .bashrc (et donc les fonctions utilisateurs et tous les trucs qui sont censés n'etre activé que pour les shells interactifs) ce qui peut poser de gros problemes. csh a ce genre de probleme mais il est moins pernicieux car tous les shells lisent le ~/.cshrc, donc on met #! /bin/csh -f dans les scripts. Pour bash, il faudrait mettre #! /bin/bash --norc pour le cas ou le script pourrait etre executé par ssh.
-- Stephane
Grrrr
On Thu, 13 Jan 2005 15:38:51 +0000, Stephane Chazelas wrote:
2005-01-13, 13:00(+01), Grrrr: [...]
/etc/bash.bashrc et ~/.bashrc ne sont executés (pas en mode sh) que par les shells interactifs qui ne sont pas de login ou les shells non-interactifs qui sont lancés par ssh (cherchez la logique).
La logique est, je crois, que: ssh <somewhere> <commande> fait exactement la même chose que: ssh <somewhere> # <commande> # exit Pour que ça marche à tous les coups, il faut bien avoir le même environnement... [...]
Ben non, justement
ssh <somewhere> # <commande>
ca lance un shell de login qui lit ~/.profile et pas ~/.bashrc.
Je viens de faire l'essai, en exportant des variables dans les scripts. Dans ce cas, bash lit bien ~/.bash_profile et pas ~/.bashrc. La vacherie est que souvent dans les squelettes de bash_profile, il lit le bashrc, ce qui donne l'impression que c'est bash qui le fait si on n'y regarde pas de trop près... Donc, effectivement, les deux cas sont bien différents.
[...]
On Thu, 13 Jan 2005 15:38:51 +0000, Stephane Chazelas wrote:
2005-01-13, 13:00(+01), Grrrr:
[...]
/etc/bash.bashrc et ~/.bashrc ne sont executés (pas en mode sh)
que par les shells interactifs qui ne sont pas de login ou les
shells non-interactifs qui sont lancés par ssh (cherchez la
logique).
La logique est, je crois, que:
ssh <somewhere> <commande>
fait exactement la même chose que:
ssh <somewhere>
# <commande>
# exit
Pour que ça marche à tous les coups, il faut bien avoir le même
environnement...
[...]
Ben non, justement
ssh <somewhere>
# <commande>
ca lance un shell de login qui lit ~/.profile et pas ~/.bashrc.
Je viens de faire l'essai, en exportant des variables dans les scripts.
Dans ce cas, bash lit bien ~/.bash_profile et pas ~/.bashrc.
La vacherie est que souvent dans les squelettes de bash_profile, il lit le
bashrc, ce qui donne l'impression que c'est bash qui le fait si on n'y
regarde pas de trop près...
Donc, effectivement, les deux cas sont bien différents.
On Thu, 13 Jan 2005 15:38:51 +0000, Stephane Chazelas wrote:
2005-01-13, 13:00(+01), Grrrr: [...]
/etc/bash.bashrc et ~/.bashrc ne sont executés (pas en mode sh) que par les shells interactifs qui ne sont pas de login ou les shells non-interactifs qui sont lancés par ssh (cherchez la logique).
La logique est, je crois, que: ssh <somewhere> <commande> fait exactement la même chose que: ssh <somewhere> # <commande> # exit Pour que ça marche à tous les coups, il faut bien avoir le même environnement... [...]
Ben non, justement
ssh <somewhere> # <commande>
ca lance un shell de login qui lit ~/.profile et pas ~/.bashrc.
Je viens de faire l'essai, en exportant des variables dans les scripts. Dans ce cas, bash lit bien ~/.bash_profile et pas ~/.bashrc. La vacherie est que souvent dans les squelettes de bash_profile, il lit le bashrc, ce qui donne l'impression que c'est bash qui le fait si on n'y regarde pas de trop près... Donc, effectivement, les deux cas sont bien différents.
[...]
jperrocheau
Stephane Chazelas wrote:
Il n'y a pas de logique pour bash, et ca depend des versions de bash et des options de compilation et des options passees et de argv[0] de suivant s'il y a une variable SSH_CLIENT ou SSH2_CLIENT dans l'environnement (et que stdin est une socket)...
Ouh! :-[ :-(
Merci quand même pour cette réponse.
[snip]
Je crois qu'il faut que je regarde combien il me reste d'aspirine avant de potasser cela ;-).
-- Jacques PERROCHEAU ________________________________________________________________________ e-mail: mailto:
Il n'y a pas de logique pour bash, et ca depend des versions de
bash et des options de compilation et des options passees et de
argv[0] de suivant s'il y a une variable SSH_CLIENT ou
SSH2_CLIENT dans l'environnement (et que stdin est une socket)...
Ouh! :-[ :-(
Merci quand même pour cette réponse.
[snip]
Je crois qu'il faut que je regarde combien il me reste d'aspirine avant
de potasser cela ;-).
--
Jacques PERROCHEAU
________________________________________________________________________
e-mail: mailto:jperrocheau@mac.com
Il n'y a pas de logique pour bash, et ca depend des versions de bash et des options de compilation et des options passees et de argv[0] de suivant s'il y a une variable SSH_CLIENT ou SSH2_CLIENT dans l'environnement (et que stdin est une socket)...
Ouh! :-[ :-(
Merci quand même pour cette réponse.
[snip]
Je crois qu'il faut que je regarde combien il me reste d'aspirine avant de potasser cela ;-).
-- Jacques PERROCHEAU ________________________________________________________________________ e-mail: mailto:
Stephane Chazelas
2005-01-13, 15:38(+00), Stephane Chazelas:
2005-01-13, 13:00(+01), Grrrr: [...]
/etc/bash.bashrc et ~/.bashrc ne sont executés (pas en mode sh) que par les shells interactifs qui ne sont pas de login ou les shells non-interactifs qui sont lancés par ssh (cherchez la logique). [...]
ssh <somewhere> # <commande>
ca lance un shell de login qui lit ~/.profile et pas ~/.bashrc.
~/.<program>rc est le fichier de customization du <program> en general... sauf pour bash.
Note que les scripts shells lancés par ssh lisent le .bashrc (et donc les fonctions utilisateurs et tous les trucs qui sont censés n'etre activé que pour les shells interactifs) ce qui peut poser de gros problemes. csh a ce genre de probleme mais il est moins pernicieux car tous les shells lisent le ~/.cshrc, donc on met #! /bin/csh -f dans les scripts. Pour bash, il faudrait mettre #! /bin/bash --norc pour le cas ou le script pourrait etre executé par ssh.
Correction, ~/.bashrc n'est pas lu par les scripts, que par bash -c 'inline-script'. Ca ne fait pas plus de sens, mais ca fait deja moins de degats.
-- Stephane
2005-01-13, 15:38(+00), Stephane Chazelas:
2005-01-13, 13:00(+01), Grrrr:
[...]
/etc/bash.bashrc et ~/.bashrc ne sont executés (pas en mode sh)
que par les shells interactifs qui ne sont pas de login ou les
shells non-interactifs qui sont lancés par ssh (cherchez la
logique).
[...]
ssh <somewhere>
# <commande>
ca lance un shell de login qui lit ~/.profile et pas ~/.bashrc.
~/.<program>rc est le fichier de customization du <program> en
general... sauf pour bash.
Note que les scripts shells lancés par ssh lisent le .bashrc (et
donc les fonctions utilisateurs et tous les trucs qui sont
censés n'etre activé que pour les shells interactifs) ce qui
peut poser de gros problemes. csh a ce genre de probleme mais il
est moins pernicieux car tous les shells lisent le ~/.cshrc,
donc on met #! /bin/csh -f dans les scripts. Pour bash, il
faudrait mettre #! /bin/bash --norc pour le cas ou le script
pourrait etre executé par ssh.
Correction, ~/.bashrc n'est pas lu par les scripts, que par bash
-c 'inline-script'. Ca ne fait pas plus de sens, mais ca fait
deja moins de degats.
/etc/bash.bashrc et ~/.bashrc ne sont executés (pas en mode sh) que par les shells interactifs qui ne sont pas de login ou les shells non-interactifs qui sont lancés par ssh (cherchez la logique). [...]
ssh <somewhere> # <commande>
ca lance un shell de login qui lit ~/.profile et pas ~/.bashrc.
~/.<program>rc est le fichier de customization du <program> en general... sauf pour bash.
Note que les scripts shells lancés par ssh lisent le .bashrc (et donc les fonctions utilisateurs et tous les trucs qui sont censés n'etre activé que pour les shells interactifs) ce qui peut poser de gros problemes. csh a ce genre de probleme mais il est moins pernicieux car tous les shells lisent le ~/.cshrc, donc on met #! /bin/csh -f dans les scripts. Pour bash, il faudrait mettre #! /bin/bash --norc pour le cas ou le script pourrait etre executé par ssh.
Correction, ~/.bashrc n'est pas lu par les scripts, que par bash -c 'inline-script'. Ca ne fait pas plus de sens, mais ca fait deja moins de degats.
-- Stephane
Stephane Chazelas
2005-01-14, 15:12(+00), Stephane Chazelas:
2005-01-13, 15:38(+00), Stephane Chazelas:
2005-01-13, 13:00(+01), Grrrr: [...]
/etc/bash.bashrc et ~/.bashrc ne sont executés (pas en mode sh) que par les shells interactifs qui ne sont pas de login ou les shells non-interactifs qui sont lancés par ssh (cherchez la logique). [...]
Correction, ~/.bashrc n'est pas lu par les scripts, que par bash -c 'inline-script'. Ca ne fait pas plus de sens, mais ca fait deja moins de degats. [...]
Note que ca marche aussi des que stdin est une socket (donc par rsh).
-- Stephane
2005-01-14, 15:12(+00), Stephane Chazelas:
2005-01-13, 15:38(+00), Stephane Chazelas:
2005-01-13, 13:00(+01), Grrrr:
[...]
/etc/bash.bashrc et ~/.bashrc ne sont executés (pas en mode sh)
que par les shells interactifs qui ne sont pas de login ou les
shells non-interactifs qui sont lancés par ssh (cherchez la
logique).
[...]
Correction, ~/.bashrc n'est pas lu par les scripts, que par bash
-c 'inline-script'. Ca ne fait pas plus de sens, mais ca fait
deja moins de degats.
[...]
Note que ca marche aussi des que stdin est une socket (donc par
rsh).
/etc/bash.bashrc et ~/.bashrc ne sont executés (pas en mode sh) que par les shells interactifs qui ne sont pas de login ou les shells non-interactifs qui sont lancés par ssh (cherchez la logique). [...]
Correction, ~/.bashrc n'est pas lu par les scripts, que par bash -c 'inline-script'. Ca ne fait pas plus de sens, mais ca fait deja moins de degats. [...]
Note que ca marche aussi des que stdin est une socket (donc par rsh).
-- Stephane
blanc
Jacques Perrocheau wrote:
Est-ce qu'une bonne âme pourrait nous faire pour bash l'équivalent de ce que le camarade Jayce a fait pour tcsh et zsh ?
Bonne idée.
Mais pourquoi ne pas te contenter d'un seul shell, tel que par exemple zsh. C'est celui que j'ai adopter depuis un an, avnt d'avoir beaucoup utilisé tcsh.
Amha zsh a les avantages de bash et de tcsh sans avoir les inconvénients de l'un et de l'autre.
JPaul. -- /==/==- Jean-Paul BLANC / /--/--// quelque-part (somewhere) |/| L | en (in) /|| = ||| FRANCE
Jacques Perrocheau <Jacques.Perrocheau@univ-rennes1.fr> wrote:
Est-ce qu'une bonne âme pourrait nous faire pour bash l'équivalent de ce
que le camarade Jayce a fait pour tcsh et zsh ?
Bonne idée.
Mais pourquoi ne pas te contenter d'un seul shell, tel que par exemple
zsh. C'est celui que j'ai adopter depuis un an, avnt d'avoir beaucoup
utilisé tcsh.
Amha zsh a les avantages de bash et de tcsh sans avoir les inconvénients
de l'un et de l'autre.
JPaul.
--
/==/==\- Jean-Paul BLANC
/ /--/--//\ quelque-part (somewhere)
|/| L |\ en (in)
/|| = |||\ FRANCE
Est-ce qu'une bonne âme pourrait nous faire pour bash l'équivalent de ce que le camarade Jayce a fait pour tcsh et zsh ?
Bonne idée.
Mais pourquoi ne pas te contenter d'un seul shell, tel que par exemple zsh. C'est celui que j'ai adopter depuis un an, avnt d'avoir beaucoup utilisé tcsh.
Amha zsh a les avantages de bash et de tcsh sans avoir les inconvénients de l'un et de l'autre.
JPaul. -- /==/==- Jean-Paul BLANC / /--/--// quelque-part (somewhere) |/| L | en (in) /|| = ||| FRANCE
Martin Costabel
Jacques Perrocheau wrote:
[]
Est-ce qu'une bonne âme pourrait nous faire pour bash l'équivalent de ce que le camarade Jayce a fait pour tcsh et zsh ?
<http://www.mosx.net/dossiers/Shell-5.shtml>
Cela aurait besoin d'une mise à jour aussi. Ça doit dater de plus de 2 ans et n'est plus vrai.
Les fichiers de démarrage de /bin/tcsh
Les fichiers standards de démarrage de tcsh sont: [snip]
Le dossier /usr/share/init n'existe plus depuis l'arrivée de Jaguar. L'ancien contenu de /usr/share/init/tcsh se trouve maintenant dans /usr/share/tcsh/examples et il n'est plus appelé automatiquement par /etc/csh.login et /etc/csh.cshrc. Mais il est utilisable comme avant si on veut (pour les vieux habitués de tcsh).
-- Martin
Jacques Perrocheau wrote:
[]
Est-ce qu'une bonne âme pourrait nous faire pour bash l'équivalent de ce
que le camarade Jayce a fait pour tcsh et zsh ?
<http://www.mosx.net/dossiers/Shell-5.shtml>
Cela aurait besoin d'une mise à jour aussi. Ça doit dater de plus de 2
ans et n'est plus vrai.
Les fichiers de démarrage de /bin/tcsh
Les fichiers standards de démarrage de tcsh sont:
[snip]
Le dossier /usr/share/init n'existe plus depuis l'arrivée de Jaguar.
L'ancien contenu de /usr/share/init/tcsh se trouve maintenant dans
/usr/share/tcsh/examples et il n'est plus appelé automatiquement par
/etc/csh.login et /etc/csh.cshrc. Mais il est utilisable comme avant si
on veut (pour les vieux habitués de tcsh).
Le dossier /usr/share/init n'existe plus depuis l'arrivée de Jaguar. L'ancien contenu de /usr/share/init/tcsh se trouve maintenant dans /usr/share/tcsh/examples et il n'est plus appelé automatiquement par /etc/csh.login et /etc/csh.cshrc. Mais il est utilisable comme avant si on veut (pour les vieux habitués de tcsh).
-- Martin
jperrocheau
JPaul wrote:
Mais pourquoi ne pas te contenter d'un seul shell, tel que par exemple zsh. C'est celui que j'ai adopter depuis un an, avant d'avoir beaucoup utilisé tcsh.
Oui peut-être... mais quand Apple aura décidé que c'est le shell proposé par défaut... ;-)
Amha zsh a les avantages de bash et de tcsh sans avoir les inconvénients de l'un et de l'autre.
-- Jacques PERROCHEAU ________________________________________________________________________ e-mail: mailto:
JPaul <blanc@empty.org> wrote:
Mais pourquoi ne pas te contenter d'un seul shell, tel que par exemple
zsh. C'est celui que j'ai adopter depuis un an, avant d'avoir beaucoup
utilisé tcsh.
Oui peut-être... mais quand Apple aura décidé que c'est le shell proposé
par défaut... ;-)
Amha zsh a les avantages de bash et de tcsh sans avoir les inconvénients
de l'un et de l'autre.
--
Jacques PERROCHEAU
________________________________________________________________________
e-mail: mailto:jperrocheau@mac.com
Mais pourquoi ne pas te contenter d'un seul shell, tel que par exemple zsh. C'est celui que j'ai adopter depuis un an, avant d'avoir beaucoup utilisé tcsh.
Oui peut-être... mais quand Apple aura décidé que c'est le shell proposé par défaut... ;-)
Amha zsh a les avantages de bash et de tcsh sans avoir les inconvénients de l'un et de l'autre.
-- Jacques PERROCHEAU ________________________________________________________________________ e-mail: mailto:
