J'ai un comportement un peu bizarre avec 'less'. =C0 chaque fois que je
l'invoque, il ne se passe rien pendant environ 5 secondes avant de
m'afficher le fichier (plus aucun probl=E8me apr=E8s). Par d=E9faut, mon
environnement contient LESSOPEN =3D "|/usr/bin/lesspipe.sh %s" et je me
suis dit que =E7a venait peut-=EAtre de l=E0.
En effet, si je supprime la variable LESSOPEN, less r=E9agit
instantan=E9ment. Mais j'ai regard=E9 le script lesspipe.sh en question,
il est tout simple, et surtout, si je le remplace par un script vide
(avec juste une ligne #!/bin/sh -), c'est toujours aussi lent. Pire
encore, si je fais, par exemple, LESSOPEN =3D "|/bin/bash -c ''" cad que
j'invoque un bash (/bin/sh est alias=E9 sur /bin/bash, chez moi) et
c'est tout, j'ai le m=EAme d=E9lai d'environ 5 secondes. Si je lance un
bash (ou lesspipe.sh, d'ailleurs) directement en ligne de commande,
j'ai le r=E9sultat instantan=E9ment, donc c'est bien li=E9 sp=E9cifiquement=
=E0
less.
Donc j'ai l'impression que le simple fait d'invoquer un pipe pour less
cause ce d=E9lai, quelque soit le contenu du fichier qui est dans
LESSOPEN...
Est-ce que quelqu'un a d=E9j=E0 vu ce genre de choses ou a une id=E9e de
comment faire ?
Dans l'imm=E9diat, j'ai enlev=E9 LESSOPEN, parce que j'en ai pas vraiment
l'usage, mais c'est une fonctionnalit=E9 agr=E9able que j'aimerais pouvoir
garder...
On Aug 14, 6:05 pm, Vincent Lefevre <vincent+ wrote:
> Ce qui est bien à l'origine de mon problème, d'ailleurs, je confirm e : > Si je supprime mon .cshrc, less met 1 à 2 secondes pour se lancer, à > peine plus que si je ne définis pas LESSOPEN.
Je crois que c'est l'option -f qui permet d'éviter que le .cshrc ne soit lu. Mais là, ce n'est pas possible de l'utiliser. "less" prend peut-être en compte la variable d'environnement SHELL pour lessopen. Tu peux toujours essayer...
Oui !!! Je n'avais pas pensé à modifier SHELL, mais c'est bien ça ! J'ai mis (pour tester) SHELL="/bin/csh -f" et là mon less se lance instantanément -- et utilise bien le programme spécifié dans LESSOPEN , j'ai vérifié, on sait jamais.
Bon, comme ça ne me semble pas une bonne idée de modifier systématiquement SHELL, je vais juste fait un alias pour less. Enfin, dès que j'aurais trouvé la syntaxe pour spécifier la valeur d'une variable pour une commande. Fichu shell mal fichu ! J'aimerais mettre alias less "SHELL='/bin/csh -f' less" (ce qui marche en bash, enfin, avec alias less=...), mais c'est pas la bonne syntaxe et j'arrive pas à la trouver... Zut, quelqu'un peut m'aider ? Bon au pire je me ferais un script less qui règle SHELL avant d'invoquer less, mais bon, un alias devrait suffire, quand même.
Merci en tout cas à tout ceux qui m'ont aidé à trouver la source du problème puis à le résoudre (enfin, presque :-) ) ! -- Rémi Moyen
On Aug 14, 6:05 pm, Vincent Lefevre <vincent+n...@vinc17.org> wrote:
> Ce qui est bien à l'origine de mon problème, d'ailleurs, je confirm e :
> Si je supprime mon .cshrc, less met 1 à 2 secondes pour se lancer, à
> peine plus que si je ne définis pas LESSOPEN.
Je crois que c'est l'option -f qui permet d'éviter que le .cshrc ne
soit lu. Mais là, ce n'est pas possible de l'utiliser. "less" prend
peut-être en compte la variable d'environnement SHELL pour lessopen.
Tu peux toujours essayer...
Oui !!!
Je n'avais pas pensé à modifier SHELL, mais c'est bien ça ! J'ai mis
(pour tester) SHELL="/bin/csh -f" et là mon less se lance
instantanément -- et utilise bien le programme spécifié dans LESSOPEN ,
j'ai vérifié, on sait jamais.
Bon, comme ça ne me semble pas une bonne idée de modifier
systématiquement SHELL, je vais juste fait un alias pour less. Enfin,
dès que j'aurais trouvé la syntaxe pour spécifier la valeur d'une
variable pour une commande. Fichu shell mal fichu ! J'aimerais mettre
alias less "SHELL='/bin/csh -f' less" (ce qui marche en bash, enfin,
avec alias less=...), mais c'est pas la bonne syntaxe et j'arrive pas
à la trouver... Zut, quelqu'un peut m'aider ? Bon au pire je me ferais
un script less qui règle SHELL avant d'invoquer less, mais bon, un
alias devrait suffire, quand même.
Merci en tout cas à tout ceux qui m'ont aidé à trouver la source du
problème puis à le résoudre (enfin, presque :-) ) !
--
Rémi Moyen
On Aug 14, 6:05 pm, Vincent Lefevre <vincent+ wrote:
> Ce qui est bien à l'origine de mon problème, d'ailleurs, je confirm e : > Si je supprime mon .cshrc, less met 1 à 2 secondes pour se lancer, à > peine plus que si je ne définis pas LESSOPEN.
Je crois que c'est l'option -f qui permet d'éviter que le .cshrc ne soit lu. Mais là, ce n'est pas possible de l'utiliser. "less" prend peut-être en compte la variable d'environnement SHELL pour lessopen. Tu peux toujours essayer...
Oui !!! Je n'avais pas pensé à modifier SHELL, mais c'est bien ça ! J'ai mis (pour tester) SHELL="/bin/csh -f" et là mon less se lance instantanément -- et utilise bien le programme spécifié dans LESSOPEN , j'ai vérifié, on sait jamais.
Bon, comme ça ne me semble pas une bonne idée de modifier systématiquement SHELL, je vais juste fait un alias pour less. Enfin, dès que j'aurais trouvé la syntaxe pour spécifier la valeur d'une variable pour une commande. Fichu shell mal fichu ! J'aimerais mettre alias less "SHELL='/bin/csh -f' less" (ce qui marche en bash, enfin, avec alias less=...), mais c'est pas la bonne syntaxe et j'arrive pas à la trouver... Zut, quelqu'un peut m'aider ? Bon au pire je me ferais un script less qui règle SHELL avant d'invoquer less, mais bon, un alias devrait suffire, quand même.
Merci en tout cas à tout ceux qui m'ont aidé à trouver la source du problème puis à le résoudre (enfin, presque :-) ) ! -- Rémi Moyen
Marc
Rémi Moyen wrote:
dès que j'aurais trouvé la syntaxe pour spécifier la valeur d'une variable pour une commande. Fichu shell mal fichu ! J'aimerais mettre alias less "SHELL='/bin/csh -f' less" (ce qui marche en bash, enfin, avec alias less=...), mais c'est pas la bonne syntaxe et j'arrive pas à la trouver... Zut, quelqu'un peut m'aider ?
La commande "env" peut aider pour ça.
Rémi Moyen wrote:
dès que j'aurais trouvé la syntaxe pour spécifier la valeur d'une
variable pour une commande. Fichu shell mal fichu ! J'aimerais mettre
alias less "SHELL='/bin/csh -f' less" (ce qui marche en bash, enfin,
avec alias less=...), mais c'est pas la bonne syntaxe et j'arrive pas
à la trouver... Zut, quelqu'un peut m'aider ?
dès que j'aurais trouvé la syntaxe pour spécifier la valeur d'une variable pour une commande. Fichu shell mal fichu ! J'aimerais mettre alias less "SHELL='/bin/csh -f' less" (ce qui marche en bash, enfin, avec alias less=...), mais c'est pas la bonne syntaxe et j'arrive pas à la trouver... Zut, quelqu'un peut m'aider ?
La commande "env" peut aider pour ça.
Rémi Moyen
On Aug 15, 1:06 pm, Marc wrote:
Rémi Moyen wrote: > dès que j'aurais trouvé la syntaxe pour spécifier la valeur d'une > variable pour une commande. Fichu shell mal fichu ! J'aimerais mettre > alias less "SHELL='/bin/csh -f' less" (ce qui marche en bash, enfin, > avec alias less=...), mais c'est pas la bonne syntaxe et j'arrive pas > à la trouver... Zut, quelqu'un peut m'aider ?
La commande "env" peut aider pour ça.
Ah oui, tiens ! Je ne connaissais env que sans aucun argument, pour afficher toutes les variables et leur valeur, je ne savais pas que ça servait à autre chose.
Bon ben c'est parfait. Avec un alias less "env SHELL='/bin/csh -f' less", tout marche bien, mon less est rapide et utilise LESSOPEN. Et en plus j'ai appris 2-3 trucs de plus sur mon système.
Merci ! -- Rémi Moyen
On Aug 15, 1:06 pm, Marc <marc.gli...@gmail.com> wrote:
Rémi Moyen wrote:
> dès que j'aurais trouvé la syntaxe pour spécifier la valeur d'une
> variable pour une commande. Fichu shell mal fichu ! J'aimerais mettre
> alias less "SHELL='/bin/csh -f' less" (ce qui marche en bash, enfin,
> avec alias less=...), mais c'est pas la bonne syntaxe et j'arrive pas
> à la trouver... Zut, quelqu'un peut m'aider ?
La commande "env" peut aider pour ça.
Ah oui, tiens ! Je ne connaissais env que sans aucun argument, pour
afficher toutes les variables et leur valeur, je ne savais pas que ça
servait à autre chose.
Bon ben c'est parfait. Avec un alias less "env SHELL='/bin/csh -f'
less", tout marche bien, mon less est rapide et utilise LESSOPEN. Et
en plus j'ai appris 2-3 trucs de plus sur mon système.
Rémi Moyen wrote: > dès que j'aurais trouvé la syntaxe pour spécifier la valeur d'une > variable pour une commande. Fichu shell mal fichu ! J'aimerais mettre > alias less "SHELL='/bin/csh -f' less" (ce qui marche en bash, enfin, > avec alias less=...), mais c'est pas la bonne syntaxe et j'arrive pas > à la trouver... Zut, quelqu'un peut m'aider ?
La commande "env" peut aider pour ça.
Ah oui, tiens ! Je ne connaissais env que sans aucun argument, pour afficher toutes les variables et leur valeur, je ne savais pas que ça servait à autre chose.
Bon ben c'est parfait. Avec un alias less "env SHELL='/bin/csh -f' less", tout marche bien, mon less est rapide et utilise LESSOPEN. Et en plus j'ai appris 2-3 trucs de plus sur mon système.
Merci ! -- Rémi Moyen
Nicolas George
Rémi Moyen wrote in message :
Bon ben c'est parfait. Avec un alias less "env SHELL='/bin/csh -f' less", tout marche bien, mon less est rapide et utilise LESSOPEN. Et en plus j'ai appris 2-3 trucs de plus sur mon système.
Ça reste quand même du bricolage. Tu ferais probablement mieux d'investir ton temps à convaincre tes responsables informatiques que leur système est tout pourri (un shell qui met vingt secondes à s'ouvrir, même il y a dix ans ça n'aurait pas été normal !) et qu'ils devraient le refaire avec des outils modernes et qui marchent.
Rémi Moyen wrote in message
<420787b3-d482-443f-99b9-1cc2f7ec6f62@26g2000hsk.googlegroups.com>:
Bon ben c'est parfait. Avec un alias less "env SHELL='/bin/csh -f'
less", tout marche bien, mon less est rapide et utilise LESSOPEN. Et
en plus j'ai appris 2-3 trucs de plus sur mon système.
Ça reste quand même du bricolage. Tu ferais probablement mieux d'investir
ton temps à convaincre tes responsables informatiques que leur système est
tout pourri (un shell qui met vingt secondes à s'ouvrir, même il y a dix ans
ça n'aurait pas été normal !) et qu'ils devraient le refaire avec des outils
modernes et qui marchent.
Bon ben c'est parfait. Avec un alias less "env SHELL='/bin/csh -f' less", tout marche bien, mon less est rapide et utilise LESSOPEN. Et en plus j'ai appris 2-3 trucs de plus sur mon système.
Ça reste quand même du bricolage. Tu ferais probablement mieux d'investir ton temps à convaincre tes responsables informatiques que leur système est tout pourri (un shell qui met vingt secondes à s'ouvrir, même il y a dix ans ça n'aurait pas été normal !) et qu'ils devraient le refaire avec des outils modernes et qui marchent.
Cyrille Lefevre
Vincent Lefevre a écrit :
Dans l'article groups.com>, Rémi Moyen écrit:
On Aug 14, 12:14 pm, Jean-Marc Bourguet wrote:
Rémi Moyen writes:
Tiens, c'est vrai que quand je lance une nouvelle console, il faut bien 10 secondes avant que j'ai le prompt, sans doute à cause de 4 0 000 fichiers de configs dans tous les sens.
Ce qui est bien à l'origine de mon problème, d'ailleurs, je confir me : Si je supprime mon .cshrc, less met 1 à 2 secondes pour se lancer, à peine plus que si je ne définis pas LESSOPEN.
Je crois que c'est l'option -f qui permet d'éviter que le .cshrc ne soit lu. Mais là, ce n'est pas possible de l'utiliser. "less" prend peut-être en compte la variable d'environnement SHELL pour lessopen. Tu peux toujours essayer...
Bonjour,
du temps ou j'utilisais csh/tcsh, et c'est loin, je me souviens d'un truc du genre : if (! $?prompt) exit si je ne me trompe en 1ère ligne du .cshrc... soit, l'équivalent de l'option -f :)
l'équivalent .ksh and co est : [[ $- != *i* ]] && return en 1ère li gne du $ENV (.kshrc en général).
Cordialement,
Cyrille Lefevre. -- mailto:Cyrille.Lefevre-news% supprimer "%nospam% et ".invalid" pour me repondre.
Vincent Lefevre a écrit :
Dans l'article <5160799f-8d78-41d4-905e-f7776629d022@e39g2000hsf.google groups.com>,
Rémi Moyen <rmoyen@gmail.com> écrit:
On Aug 14, 12:14 pm, Jean-Marc Bourguet <j...@bourguet.org> wrote:
Rémi Moyen <rmo...@gmail.com> writes:
Tiens, c'est vrai que quand je lance une nouvelle console, il faut
bien 10 secondes avant que j'ai le prompt, sans doute à cause de 4 0
000 fichiers de configs dans tous les sens.
Ce qui est bien à l'origine de mon problème, d'ailleurs, je confir me :
Si je supprime mon .cshrc, less met 1 à 2 secondes pour se lancer, à
peine plus que si je ne définis pas LESSOPEN.
Je crois que c'est l'option -f qui permet d'éviter que le .cshrc ne
soit lu. Mais là, ce n'est pas possible de l'utiliser. "less" prend
peut-être en compte la variable d'environnement SHELL pour lessopen.
Tu peux toujours essayer...
Bonjour,
du temps ou j'utilisais csh/tcsh, et c'est loin, je me souviens d'un
truc du genre : if (! $?prompt) exit si je ne me trompe en 1ère ligne
du .cshrc... soit, l'équivalent de l'option -f :)
l'équivalent .ksh and co est : [[ $- != *i* ]] && return en 1ère li gne
du $ENV (.kshrc en général).
Cordialement,
Cyrille Lefevre.
--
mailto:Cyrille.Lefevre-news%nospam@laposte.net.invalid
supprimer "%nospam% et ".invalid" pour me repondre.
Tiens, c'est vrai que quand je lance une nouvelle console, il faut bien 10 secondes avant que j'ai le prompt, sans doute à cause de 4 0 000 fichiers de configs dans tous les sens.
Ce qui est bien à l'origine de mon problème, d'ailleurs, je confir me : Si je supprime mon .cshrc, less met 1 à 2 secondes pour se lancer, à peine plus que si je ne définis pas LESSOPEN.
Je crois que c'est l'option -f qui permet d'éviter que le .cshrc ne soit lu. Mais là, ce n'est pas possible de l'utiliser. "less" prend peut-être en compte la variable d'environnement SHELL pour lessopen. Tu peux toujours essayer...
Bonjour,
du temps ou j'utilisais csh/tcsh, et c'est loin, je me souviens d'un truc du genre : if (! $?prompt) exit si je ne me trompe en 1ère ligne du .cshrc... soit, l'équivalent de l'option -f :)
l'équivalent .ksh and co est : [[ $- != *i* ]] && return en 1ère li gne du $ENV (.kshrc en général).
Cordialement,
Cyrille Lefevre. -- mailto:Cyrille.Lefevre-news% supprimer "%nospam% et ".invalid" pour me repondre.
Vincent Lefevre
Bonjour,
Dans l'article , Cyrille Lefevre <cyrille.lefevre-news% écrit:
du temps ou j'utilisais csh/tcsh, et c'est loin, je me souviens d'un truc du genre : if (! $?prompt) exit si je ne me trompe en 1ère ligne du .cshrc... soit, l'équivalent de l'option -f :)
Tester la non-existence de $prompt n'est pas suffisant. Il se peut également que $prompt existe et soit vide; si on ne teste pas ce cas-là, ça pose des problèmes avec certains scripts csh, comme "which" sous Solaris.
On peut commencer par faire:
if ($?prompt) then if ("$prompt" == "") then unset prompt endif endif
Dans l'article <48A6477D.4090802@laposte.net.invalid>,
Cyrille Lefevre <cyrille.lefevre-news%nospam@laposte.net.invalid> écrit:
du temps ou j'utilisais csh/tcsh, et c'est loin, je me souviens d'un
truc du genre : if (! $?prompt) exit si je ne me trompe en 1ère ligne
du .cshrc... soit, l'équivalent de l'option -f :)
Tester la non-existence de $prompt n'est pas suffisant. Il se peut
également que $prompt existe et soit vide; si on ne teste pas ce
cas-là, ça pose des problèmes avec certains scripts csh, comme "which"
sous Solaris.
On peut commencer par faire:
if ($?prompt) then
if ("$prompt" == "") then
unset prompt
endif
endif
Dans l'article , Cyrille Lefevre <cyrille.lefevre-news% écrit:
du temps ou j'utilisais csh/tcsh, et c'est loin, je me souviens d'un truc du genre : if (! $?prompt) exit si je ne me trompe en 1ère ligne du .cshrc... soit, l'équivalent de l'option -f :)
Tester la non-existence de $prompt n'est pas suffisant. Il se peut également que $prompt existe et soit vide; si on ne teste pas ce cas-là, ça pose des problèmes avec certains scripts csh, comme "which" sous Solaris.
On peut commencer par faire:
if ($?prompt) then if ("$prompt" == "") then unset prompt endif endif
On Aug 15, 1:51 pm, Nicolas George <nicolas$ wrote:
> Bon ben c'est parfait. Avec un alias less "env SHELL='/bin/csh -f' > less", tout marche bien, mon less est rapide et utilise LESSOPEN. Et > en plus j'ai appris 2-3 trucs de plus sur mon système.
Ça reste quand même du bricolage. Tu ferais probablement mieux d'inve stir ton temps à convaincre tes responsables informatiques que leur systèm e est tout pourri (un shell qui met vingt secondes à s'ouvrir, même il y a dix ans ça n'aurait pas été normal !) et qu'ils devraient le refaire avec des outils modernes et qui marchent.
Bof. Mes responsables informatiques gèrent plusieurs milliers de postes dans le monde, je doute qu'ils prêtent beaucoup d'attention à ce que je pourrais leur dire -- et quand à juger de la qualité de leurs scripts, c'est bien en dehors de mes capacités. Évidemment, dans l'absolu on pourrait sans doute faire mieux, mais vu le nombre de systèmes maisons hérités de partout qu'ils doivent faire cohabiter, j e me garderais bien de proclamer arbitrairement que ce qu'ils font est "tout pourri".
Sans compter qu'on est en pleine migration de pas mal de choses, donc je vais au minimum attendre que ce soit fini avant de râler, les choses vont peut-être s'améliorer quand la nouvelle architecture sera en place ! -- Rémi Moyen
On Aug 15, 1:51 pm, Nicolas George <nicolas$geo...@salle-s.org> wrote:
> Bon ben c'est parfait. Avec un alias less "env SHELL='/bin/csh -f'
> less", tout marche bien, mon less est rapide et utilise LESSOPEN. Et
> en plus j'ai appris 2-3 trucs de plus sur mon système.
Ça reste quand même du bricolage. Tu ferais probablement mieux d'inve stir
ton temps à convaincre tes responsables informatiques que leur systèm e est
tout pourri (un shell qui met vingt secondes à s'ouvrir, même il y a dix ans
ça n'aurait pas été normal !) et qu'ils devraient le refaire avec des outils
modernes et qui marchent.
Bof. Mes responsables informatiques gèrent plusieurs milliers de
postes dans le monde, je doute qu'ils prêtent beaucoup d'attention à
ce que je pourrais leur dire -- et quand à juger de la qualité de
leurs scripts, c'est bien en dehors de mes capacités. Évidemment, dans
l'absolu on pourrait sans doute faire mieux, mais vu le nombre de
systèmes maisons hérités de partout qu'ils doivent faire cohabiter, j e
me garderais bien de proclamer arbitrairement que ce qu'ils font est
"tout pourri".
Sans compter qu'on est en pleine migration de pas mal de choses, donc
je vais au minimum attendre que ce soit fini avant de râler, les
choses vont peut-être s'améliorer quand la nouvelle architecture sera
en place !
--
Rémi Moyen
On Aug 15, 1:51 pm, Nicolas George <nicolas$ wrote:
> Bon ben c'est parfait. Avec un alias less "env SHELL='/bin/csh -f' > less", tout marche bien, mon less est rapide et utilise LESSOPEN. Et > en plus j'ai appris 2-3 trucs de plus sur mon système.
Ça reste quand même du bricolage. Tu ferais probablement mieux d'inve stir ton temps à convaincre tes responsables informatiques que leur systèm e est tout pourri (un shell qui met vingt secondes à s'ouvrir, même il y a dix ans ça n'aurait pas été normal !) et qu'ils devraient le refaire avec des outils modernes et qui marchent.
Bof. Mes responsables informatiques gèrent plusieurs milliers de postes dans le monde, je doute qu'ils prêtent beaucoup d'attention à ce que je pourrais leur dire -- et quand à juger de la qualité de leurs scripts, c'est bien en dehors de mes capacités. Évidemment, dans l'absolu on pourrait sans doute faire mieux, mais vu le nombre de systèmes maisons hérités de partout qu'ils doivent faire cohabiter, j e me garderais bien de proclamer arbitrairement que ce qu'ils font est "tout pourri".
Sans compter qu'on est en pleine migration de pas mal de choses, donc je vais au minimum attendre que ce soit fini avant de râler, les choses vont peut-être s'améliorer quand la nouvelle architecture sera en place ! -- Rémi Moyen
Rémi Moyen
On Aug 17, 12:01 am, Vincent Lefevre <vincent+ wrote:
> du temps ou j'utilisais csh/tcsh, et c'est loin, je me souviens d'un > truc du genre : if (! $?prompt) exit si je ne me trompe en 1ère ligne > du .cshrc... soit, l'équivalent de l'option -f :)
Tester la non-existence de $prompt n'est pas suffisant. Il se peut également que $prompt existe et soit vide; si on ne teste pas ce cas-là, ça pose des problèmes avec certains scripts csh, comme "whi ch" sous Solaris.
Jean-Marc Bourguet m'avait déjà soufflé un fragement de code que j'utilisais jusqu'à récemment :
if ($?prompt != 0) then if ("$prompt" != "" && $?tcsh == 0) then setenv SHELL /bin/tcsh exec $SHELL -l $* endif endif
Mais depuis quelques jours une grosse migration des systèmes est en cours et avec la nouvelle configuration, ce passage n'a plus l'air d'avoir l'effet que je voudrais. Je vais attendre que les choses soient stabilisées avant de creuser ça. -- Rémi Moyen
On Aug 17, 12:01 am, Vincent Lefevre <vincent+n...@vinc17.org> wrote:
> du temps ou j'utilisais csh/tcsh, et c'est loin, je me souviens d'un
> truc du genre : if (! $?prompt) exit si je ne me trompe en 1ère ligne
> du .cshrc... soit, l'équivalent de l'option -f :)
Tester la non-existence de $prompt n'est pas suffisant. Il se peut
également que $prompt existe et soit vide; si on ne teste pas ce
cas-là, ça pose des problèmes avec certains scripts csh, comme "whi ch"
sous Solaris.
Jean-Marc Bourguet m'avait déjà soufflé un fragement de code que
j'utilisais jusqu'à récemment :
if ($?prompt != 0) then
if ("$prompt" != "" && $?tcsh == 0) then
setenv SHELL /bin/tcsh
exec $SHELL -l $*
endif
endif
Mais depuis quelques jours une grosse migration des systèmes est en
cours et avec la nouvelle configuration, ce passage n'a plus l'air
d'avoir l'effet que je voudrais. Je vais attendre que les choses
soient stabilisées avant de creuser ça.
--
Rémi Moyen
On Aug 17, 12:01 am, Vincent Lefevre <vincent+ wrote:
> du temps ou j'utilisais csh/tcsh, et c'est loin, je me souviens d'un > truc du genre : if (! $?prompt) exit si je ne me trompe en 1ère ligne > du .cshrc... soit, l'équivalent de l'option -f :)
Tester la non-existence de $prompt n'est pas suffisant. Il se peut également que $prompt existe et soit vide; si on ne teste pas ce cas-là, ça pose des problèmes avec certains scripts csh, comme "whi ch" sous Solaris.
Jean-Marc Bourguet m'avait déjà soufflé un fragement de code que j'utilisais jusqu'à récemment :
if ($?prompt != 0) then if ("$prompt" != "" && $?tcsh == 0) then setenv SHELL /bin/tcsh exec $SHELL -l $* endif endif
Mais depuis quelques jours une grosse migration des systèmes est en cours et avec la nouvelle configuration, ce passage n'a plus l'air d'avoir l'effet que je voudrais. Je vais attendre que les choses soient stabilisées avant de creuser ça. -- Rémi Moyen