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 !
In article <46dafbdd$0$8790$, Nicolas George <nicolas$ wrote:
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.
ah oui, c'est pas exécuté par le xterm de x11, mince ! mais bon, normalement je vais jamais m'en servir non plus :-)
une règle absolue, c'est que ça exécute tjr soit ~/.profile soit ~/.bashrc , de façon exclusive, c'est bien ça ? (étant entendu qu'il n'y a pas d'autres fichiers existants, sinon c'est trop compliqué :-) )
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.
c'est pas du bash, c'est juste une suite de commandes :-)
sinon, le langage de /bin/sh est variable ? je croyais que c'est ce qu'il fallait faire pour avoir qqch le plus portable possible
ps : personne ne peut me répondre, pour la complétion ?
-- j'agis contre l'assistanat, je travaille dans une SCOP !
In article <46dafbdd$0$8790$426a74cc@news.free.fr>,
Nicolas George <nicolas$george@salle-s.org> wrote:
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.
ah oui, c'est pas exécuté par le xterm de x11, mince !
mais bon, normalement je vais jamais m'en servir non plus :-)
une règle absolue, c'est que ça exécute tjr soit ~/.profile soit
~/.bashrc , de façon exclusive, c'est bien ça ?
(étant entendu qu'il n'y a pas d'autres fichiers existants, sinon c'est
trop compliqué :-) )
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.
c'est pas du bash, c'est juste une suite de commandes :-)
sinon, le langage de /bin/sh est variable ?
je croyais que c'est ce qu'il fallait faire pour avoir qqch le plus
portable possible
ps : personne ne peut me répondre, pour la complétion ?
--
j'agis contre l'assistanat, je travaille dans une SCOP !
In article <46dafbdd$0$8790$, Nicolas George <nicolas$ wrote:
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.
ah oui, c'est pas exécuté par le xterm de x11, mince ! mais bon, normalement je vais jamais m'en servir non plus :-)
une règle absolue, c'est que ça exécute tjr soit ~/.profile soit ~/.bashrc , de façon exclusive, c'est bien ça ? (étant entendu qu'il n'y a pas d'autres fichiers existants, sinon c'est trop compliqué :-) )
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.
c'est pas du bash, c'est juste une suite de commandes :-)
sinon, le langage de /bin/sh est variable ? je croyais que c'est ce qu'il fallait faire pour avoir qqch le plus portable possible
ps : personne ne peut me répondre, pour la complétion ?
-- j'agis contre l'assistanat, je travaille dans une SCOP !
Thomas
In article , Stephane Chazelas wrote:
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).
merci, c'est bon à savoir :-)
- 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).
merci :-)
-- j'agis contre l'assistanat, je travaille dans une SCOP !
In article <slrnfdlvik.k9r.stephane.chazelas@spam.is.invalid>,
Stephane Chazelas <cette.adresse@est.invalid> wrote:
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).
merci, c'est bon à savoir :-)
- 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).
merci :-)
--
j'agis contre l'assistanat, je travaille dans une SCOP !
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).
merci, c'est bon à savoir :-)
- 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).
merci :-)
-- j'agis contre l'assistanat, je travaille dans une SCOP !
Donc, par exemple, _chez moi_, je peux utiliser toutes sortes de trucs spécifiques à bash dans des scripts commençant par #!/bin/sh.
Pourtant le man de bash dit:
| If bash is invoked with the name sh, it tries to mimic the startup | behavior of historical versions of sh as closely as possible, while | conforming to the POSIX standard as well. [...]
Il dit bien "_tries_ to mimic", mais il y a quand meme une option --posix, activée par défaut quand le shell est appelé par sh.
Donc, par exemple, _chez moi_, je peux utiliser toutes sortes de trucs
spécifiques à bash dans des scripts commençant par #!/bin/sh.
Pourtant le man de bash dit:
| If bash is invoked with the name sh, it tries to mimic the startup
| behavior of historical versions of sh as closely as possible, while
| conforming to the POSIX standard as well. [...]
Il dit bien "_tries_ to mimic", mais il y a quand meme une option
--posix, activée par défaut quand le shell est appelé par sh.
Donc, par exemple, _chez moi_, je peux utiliser toutes sortes de trucs spécifiques à bash dans des scripts commençant par #!/bin/sh.
Pourtant le man de bash dit:
| If bash is invoked with the name sh, it tries to mimic the startup | behavior of historical versions of sh as closely as possible, while | conforming to the POSIX standard as well. [...]
Il dit bien "_tries_ to mimic", mais il y a quand meme une option --posix, activée par défaut quand le shell est appelé par sh.
Donc, par exemple, _chez moi_, je peux utiliser toutes sortes de trucs spécifiques à bash dans des scripts commençant par #!/bin/sh.
Pourtant le man de bash dit:
| If bash is invoked with the name sh, it tries to mimic the startup | behavior of historical versions of sh as closely as possible, while | conforming to the POSIX standard as well. [...]
Il dit bien "_tries_ to mimic", mais il y a quand meme une option --posix, activée par défaut quand le shell est appelé par sh.
-- Alain.
merci à tous pour toutes les infos :-)
-- j'agis contre l'assistanat, je travaille dans une SCOP !
In article <87642r24s4.fsf@dpt-info.u-strasbg.fr>,
Alain Ketterlin <alain@dpt-info.u-strasbg.fr> wrote:
Donc, par exemple, _chez moi_, je peux utiliser toutes sortes de trucs
spécifiques à bash dans des scripts commençant par #!/bin/sh.
Pourtant le man de bash dit:
| If bash is invoked with the name sh, it tries to mimic the startup
| behavior of historical versions of sh as closely as possible, while
| conforming to the POSIX standard as well. [...]
Il dit bien "_tries_ to mimic", mais il y a quand meme une option
--posix, activée par défaut quand le shell est appelé par sh.
-- Alain.
merci à tous pour toutes les infos :-)
--
j'agis contre l'assistanat, je travaille dans une SCOP !
Donc, par exemple, _chez moi_, je peux utiliser toutes sortes de trucs spécifiques à bash dans des scripts commençant par #!/bin/sh.
Pourtant le man de bash dit:
| If bash is invoked with the name sh, it tries to mimic the startup | behavior of historical versions of sh as closely as possible, while | conforming to the POSIX standard as well. [...]
Il dit bien "_tries_ to mimic", mais il y a quand meme une option --posix, activée par défaut quand le shell est appelé par sh.
-- Alain.
merci à tous pour toutes les infos :-)
-- j'agis contre l'assistanat, je travaille dans une SCOP !
Vincent Lefevre
Dans l'article <46da93e3$0$16662$, Nicolas George <nicolas$ écrit:
Vincent Lefevre wrote in message <20070902094539$:
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.
Pas forcément. Essaie "ssh -t <host> zsh" (sans option -l).
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.
Il y a le classique:
if [ "$PS1" ]; then
définition des alias
fi
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.
Dans l'article <46da93e3$0$16662$426a74cc@news.free.fr>,
Nicolas George <nicolas$george@salle-s.org> écrit:
Vincent Lefevre wrote in message
<20070902094539$0deb@prunille.vinc17.org>:
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.
Pas forcément. Essaie "ssh -t <host> zsh" (sans option -l).
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.
Il y a le classique:
if [ "$PS1" ]; then
définition des alias
fi
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.
Dans l'article <46da93e3$0$16662$, Nicolas George <nicolas$ écrit:
Vincent Lefevre wrote in message <20070902094539$:
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.
Pas forcément. Essaie "ssh -t <host> zsh" (sans option -l).
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.
Il y a le classique:
if [ "$PS1" ]; then
définition des alias
fi
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.
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.
Il y a le classique:
if [ "$PS1" ]; then
définition des alias
fi
beaucoup font PS1=... export PS1
case $- in *i*) mode interactif ;; *) mode batch if [[ -t 0 ]]; then lance par cron ou dans un pipe en entree elif [[ -t 1 ]]; then dans un pipe en sortie fi ;; esac
est plus fiable qq soit le shell utilise.
dans le $ENV ou $BASH_ENV, j'ai l'habitude de faire
[[ $- != *i* ]] && return
au tout debut, histoire de ne pas poluer les batchs.
Regards, Cordialement,
Cyrille Lefevre. -- mailto:Cyrille.Lefevre-news% supprimer "%nospam% et ".invalid" pour me repondre. remove "%nospam" and ".invalid" to answer me.
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.
Il y a le classique:
if [ "$PS1" ]; then
définition des alias
fi
beaucoup font PS1=... export PS1
case $- in
*i*)
mode interactif ;;
*)
mode batch
if [[ -t 0 ]]; then
lance par cron ou dans un pipe en entree
elif [[ -t 1 ]]; then
dans un pipe en sortie
fi
;;
esac
est plus fiable qq soit le shell utilise.
dans le $ENV ou $BASH_ENV, j'ai l'habitude de faire
[[ $- != *i* ]] && return
au tout debut, histoire de ne pas poluer les batchs.
Regards, Cordialement,
Cyrille Lefevre.
--
mailto:Cyrille.Lefevre-news%nospam@laposte.net.invalid
supprimer "%nospam% et ".invalid" pour me repondre.
remove "%nospam" and ".invalid" to answer me.
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.
Il y a le classique:
if [ "$PS1" ]; then
définition des alias
fi
beaucoup font PS1=... export PS1
case $- in *i*) mode interactif ;; *) mode batch if [[ -t 0 ]]; then lance par cron ou dans un pipe en entree elif [[ -t 1 ]]; then dans un pipe en sortie fi ;; esac
est plus fiable qq soit le shell utilise.
dans le $ENV ou $BASH_ENV, j'ai l'habitude de faire
[[ $- != *i* ]] && return
au tout debut, histoire de ne pas poluer les batchs.
Regards, Cordialement,
Cyrille Lefevre. -- mailto:Cyrille.Lefevre-news% supprimer "%nospam% et ".invalid" pour me repondre. remove "%nospam" and ".invalid" to answer me.
Stephane Chazelas
2007-09-10, 18:55(+00), Vincent Lefevre: [...]
Il y a le classique:
if [ "$PS1" ]; then
Pas une bonne idee, $PS1 peut se trouver dans l'environnement. Et la syntaxe est [ -n "$PS1" ]
Utiliser $-:
case $- in (*i*) ... esac
-- Stéphane
2007-09-10, 18:55(+00), Vincent Lefevre:
[...]
Il y a le classique:
if [ "$PS1" ]; then
Pas une bonne idee, $PS1 peut se trouver dans l'environnement.
Et la syntaxe est [ -n "$PS1" ]
Pas une bonne idee, $PS1 peut se trouver dans l'environnement. Et la syntaxe est [ -n "$PS1" ]
Utiliser $-:
case $- in (*i*) ... esac
-- Stéphane
Vincent Lefevre
Dans l'article <fc4f1g$1nch$, Cyrille Lefevre <cyrille.lefevre-news% écrit:
Il y a le classique:
if [ "$PS1" ]; then
définition des alias
fi
beaucoup font PS1=... export PS1
C'est un bug. Ils devraient tester $PS1 avant de le forcer à la valeur voulue.
case $- in *i*) mode interactif ;; *) mode batch if [[ -t 0 ]]; then lance par cron ou dans un pipe en entree elif [[ -t 1 ]]; then dans un pipe en sortie fi ;; esac
est plus fiable qq soit le shell utilise.
Ça doit fonctionner avec bash, mais pas quelque soit le shell utilisé: ça ne semble pas être POSIX et n'est pas compatible avec le /bin/sh de Solaris:
bar:~> sh $ echo $- s
Pas de i...
En tout cas, le /etc/bash.bashrc de Debian utilise:
# If not running interactively, don't do anything [ -z "$PS1" ] && return
Dans l'article <fc4f1g$1nch$1@talisker.lacave.net>,
Cyrille Lefevre <cyrille.lefevre-news%nospam@laposte.net.invalid> écrit:
Il y a le classique:
if [ "$PS1" ]; then
définition des alias
fi
beaucoup font PS1=... export PS1
C'est un bug. Ils devraient tester $PS1 avant de le forcer à la valeur
voulue.
case $- in
*i*)
mode interactif ;;
*)
mode batch
if [[ -t 0 ]]; then
lance par cron ou dans un pipe en entree
elif [[ -t 1 ]]; then
dans un pipe en sortie
fi
;;
esac
est plus fiable qq soit le shell utilise.
Ça doit fonctionner avec bash, mais pas quelque soit le shell utilisé:
ça ne semble pas être POSIX et n'est pas compatible avec le /bin/sh de
Solaris:
bar:~> sh
$ echo $-
s
Pas de i...
En tout cas, le /etc/bash.bashrc de Debian utilise:
# If not running interactively, don't do anything
[ -z "$PS1" ] && return
Dans l'article <fc4f1g$1nch$, Cyrille Lefevre <cyrille.lefevre-news% écrit:
Il y a le classique:
if [ "$PS1" ]; then
définition des alias
fi
beaucoup font PS1=... export PS1
C'est un bug. Ils devraient tester $PS1 avant de le forcer à la valeur voulue.
case $- in *i*) mode interactif ;; *) mode batch if [[ -t 0 ]]; then lance par cron ou dans un pipe en entree elif [[ -t 1 ]]; then dans un pipe en sortie fi ;; esac
est plus fiable qq soit le shell utilise.
Ça doit fonctionner avec bash, mais pas quelque soit le shell utilisé: ça ne semble pas être POSIX et n'est pas compatible avec le /bin/sh de Solaris:
bar:~> sh $ echo $- s
Pas de i...
En tout cas, le /etc/bash.bashrc de Debian utilise:
# If not running interactively, don't do anything [ -z "$PS1" ] && return
