Ma question va peut être vous paraître un peut conne... mais pourquoi
dans le shell de mac os X (et dans tout les unix visiblement), il y a
tant de shell différents pour le terminal ?
Attention, ce n'est pas une critique, mais une simple question, très
conne je l'admet....
--
<http://www.clampin.com/>, l'actualité Mac vue par Clampin
Le seul à déconseiller c'est (t)csh. Allons bon... Tu dis que tous se valent et là tu fais une distinction
;-)
En Unix, il y a deux choses importantes : il y a toujours une exception. :-)
-- Je pense qu'il vaut mieux avoir une carte american express, avec laquelle on ne peut être piégé. Annule ta visa et prends l'amex, qui est d'ailleurs plus universellement acceptée. -+- LC in <http://www.le-gnu.net> : Bien répndre aux signatures -+-
Le seul à déconseiller c'est (t)csh.
Allons bon... Tu dis que tous se valent et là tu fais une distinction
;-)
En Unix, il y a deux choses importantes : il y a toujours une
exception. :-)
--
Je pense qu'il vaut mieux avoir une carte american express, avec
laquelle on ne peut être piégé. Annule ta visa et prends l'amex, qui est
d'ailleurs plus universellement acceptée.
-+- LC in <http://www.le-gnu.net> : Bien répndre aux signatures -+-
Le seul à déconseiller c'est (t)csh. Allons bon... Tu dis que tous se valent et là tu fais une distinction
;-)
En Unix, il y a deux choses importantes : il y a toujours une exception. :-)
-- Je pense qu'il vaut mieux avoir une carte american express, avec laquelle on ne peut être piégé. Annule ta visa et prends l'amex, qui est d'ailleurs plus universellement acceptée. -+- LC in <http://www.le-gnu.net> : Bien répndre aux signatures -+-
laurent.pertois
Stephane Dupille <sdupille+ wrote:
Allons bon... Tu dis que tous se valent et là tu fais une distinction ;-)
En Unix, il y a deux choses importantes : il y a toujours une exception. :-)
MDR :)
Bon, pourquoi ce racisme anti-tcsh alors qu'il est par défaut sur bien des BSD ? il est vraiment si mauvais ? je parle en tant que shell de base, bien sûr, pour naviguer, lancer quelques commandes simples...
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Stephane Dupille <sdupille+news@teaser.fr> wrote:
Allons bon... Tu dis que tous se valent et là tu fais une distinction
;-)
En Unix, il y a deux choses importantes : il y a toujours une
exception. :-)
MDR :)
Bon, pourquoi ce racisme anti-tcsh alors qu'il est par défaut sur bien
des BSD ? il est vraiment si mauvais ? je parle en tant que shell de
base, bien sûr, pour naviguer, lancer quelques commandes simples...
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Allons bon... Tu dis que tous se valent et là tu fais une distinction ;-)
En Unix, il y a deux choses importantes : il y a toujours une exception. :-)
MDR :)
Bon, pourquoi ce racisme anti-tcsh alors qu'il est par défaut sur bien des BSD ? il est vraiment si mauvais ? je parle en tant que shell de base, bien sûr, pour naviguer, lancer quelques commandes simples...
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Stephane Dupille
Bon, pourquoi ce racisme anti-tcsh alors qu'il est par défaut sur bien des BSD ? il est vraiment si mauvais ? je parle en tant que shell de base, bien sûr, pour naviguer, lancer quelques commandes simples...
Pour une utilisation interactive, ça peut encore aller, mais pour programmer, c'est une horreur : il est tellement différent des autres qu'il est contre-intuitif, alors que ksh, zsh, bash, sh, ash et les autres ont tous pour base le Bourne.
Sinon, il y a une FAQ sur le sujet (en anglais) : http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/
-- J'ai essayé de creer un news un alt.west.virginia ou sur d'autres alt.west.wirginia.xxx mais quand je vais sur ces forums rien n'apparait? l'emetteur d'un new recoit il un avertissement si celui ci est censuré? -+- LM in: <http://www.le-gnu.net> - Bien sansurer ses news sur C-I -+-
Bon, pourquoi ce racisme anti-tcsh alors qu'il est par défaut sur bien
des BSD ? il est vraiment si mauvais ? je parle en tant que shell de
base, bien sûr, pour naviguer, lancer quelques commandes simples...
Pour une utilisation interactive, ça peut encore aller, mais pour
programmer, c'est une horreur : il est tellement différent des autres
qu'il est contre-intuitif, alors que ksh, zsh, bash, sh, ash et les
autres ont tous pour base le Bourne.
Sinon, il y a une FAQ sur le sujet (en anglais) :
http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/
--
J'ai essayé de creer un news un alt.west.virginia ou sur d'autres
alt.west.wirginia.xxx mais quand je vais sur ces forums rien n'apparait?
l'emetteur d'un new recoit il un avertissement si celui ci est censuré?
-+- LM in: <http://www.le-gnu.net> - Bien sansurer ses news sur C-I -+-
Bon, pourquoi ce racisme anti-tcsh alors qu'il est par défaut sur bien des BSD ? il est vraiment si mauvais ? je parle en tant que shell de base, bien sûr, pour naviguer, lancer quelques commandes simples...
Pour une utilisation interactive, ça peut encore aller, mais pour programmer, c'est une horreur : il est tellement différent des autres qu'il est contre-intuitif, alors que ksh, zsh, bash, sh, ash et les autres ont tous pour base le Bourne.
Sinon, il y a une FAQ sur le sujet (en anglais) : http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/
-- J'ai essayé de creer un news un alt.west.virginia ou sur d'autres alt.west.wirginia.xxx mais quand je vais sur ces forums rien n'apparait? l'emetteur d'un new recoit il un avertissement si celui ci est censuré? -+- LM in: <http://www.le-gnu.net> - Bien sansurer ses news sur C-I -+-
laurent.pertois
Stephane Dupille <sdupille+ wrote:
Pour une utilisation interactive, ça peut encore aller,
Ok, je n'en suis que là, c'est pour ça qu'il me va bien :)
mais pour programmer, c'est une horreur : il est tellement différent des autres qu'il est contre-intuitif, alors que ksh, zsh, bash, sh, ash et les autres ont tous pour base le Bourne.
Forcément, pourtant, l'idée de (t)csh n'était-elle pas de s'inspirer du c ?
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Stephane Dupille <sdupille+news@teaser.fr> wrote:
Pour une utilisation interactive, ça peut encore aller,
Ok, je n'en suis que là, c'est pour ça qu'il me va bien :)
mais pour
programmer, c'est une horreur : il est tellement différent des autres
qu'il est contre-intuitif, alors que ksh, zsh, bash, sh, ash et les
autres ont tous pour base le Bourne.
Forcément, pourtant, l'idée de (t)csh n'était-elle pas de s'inspirer du
c ?
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Pour une utilisation interactive, ça peut encore aller,
Ok, je n'en suis que là, c'est pour ça qu'il me va bien :)
mais pour programmer, c'est une horreur : il est tellement différent des autres qu'il est contre-intuitif, alors que ksh, zsh, bash, sh, ash et les autres ont tous pour base le Bourne.
Forcément, pourtant, l'idée de (t)csh n'était-elle pas de s'inspirer du c ?
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Stephane Dupille
programmer, c'est une horreur : il est tellement différent des autres qu'il est contre-intuitif, alors que ksh, zsh, bash, sh, ash et les autres ont tous pour base le Bourne. Forcément, pourtant, l'idée de (t)csh n'était-elle pas de s'inspirer du
c ?
En théorie oui, mais il est particulièrement incohérent. Par exemple, pour créer une variable du shell : fooºr Pour créer une variable d'env : setenv foo bar Dans un cas il faut un =, dans l'autre, non.
Dans un Bourne Shell, c'est beaucoup plus cohérents, plus limpide.
Et si c'est pour avoir une syntaxe à la C, autant utiliser C, hein ! Sinon Perl.
-- En effet, les FAQ sont des "conseils d'utilisation" et non des règles à respecter. -+-BC in <http://www.le-gnu.net> Si tu veux du CU, retourne à la FAQ-+-
programmer, c'est une horreur : il est tellement différent des autres
qu'il est contre-intuitif, alors que ksh, zsh, bash, sh, ash et les
autres ont tous pour base le Bourne.
Forcément, pourtant, l'idée de (t)csh n'était-elle pas de s'inspirer du
c ?
En théorie oui, mais il est particulièrement incohérent.
Par exemple, pour créer une variable du shell :
fooºr
Pour créer une variable d'env :
setenv foo bar
Dans un cas il faut un =, dans l'autre, non.
Dans un Bourne Shell, c'est beaucoup plus cohérents, plus limpide.
Et si c'est pour avoir une syntaxe à la C, autant utiliser C, hein !
Sinon Perl.
--
En effet, les FAQ sont des "conseils d'utilisation"
et non des règles à respecter.
-+-BC in <http://www.le-gnu.net> Si tu veux du CU, retourne à la FAQ-+-
programmer, c'est une horreur : il est tellement différent des autres qu'il est contre-intuitif, alors que ksh, zsh, bash, sh, ash et les autres ont tous pour base le Bourne. Forcément, pourtant, l'idée de (t)csh n'était-elle pas de s'inspirer du
c ?
En théorie oui, mais il est particulièrement incohérent. Par exemple, pour créer une variable du shell : fooºr Pour créer une variable d'env : setenv foo bar Dans un cas il faut un =, dans l'autre, non.
Dans un Bourne Shell, c'est beaucoup plus cohérents, plus limpide.
Et si c'est pour avoir une syntaxe à la C, autant utiliser C, hein ! Sinon Perl.
-- En effet, les FAQ sont des "conseils d'utilisation" et non des règles à respecter. -+-BC in <http://www.le-gnu.net> Si tu veux du CU, retourne à la FAQ-+-
laurent.pertois
Stephane Dupille <sdupille+ wrote:
Forcément, pourtant, l'idée de (t)csh n'était-elle pas de s'inspirer du c ?
En théorie oui, mais il est particulièrement incohérent.
Rhooohhhhh :-D
Par exemple, pour créer une variable du shell : fooºr
Ah vi...
Pour créer une variable d'env : setenv foo bar Dans un cas il faut un =, dans l'autre, non.
Ah oui, pas logique, effectivement, je suis d'accord.
Dans un Bourne Shell, c'est beaucoup plus cohérents, plus limpide.
Ben, moi, j'ai du mal pourtant, mais il faut dire que je me plonge dans le truc une fois tous les 6 mois, ça n'aide pas ;-)
Et si c'est pour avoir une syntaxe à la C, autant utiliser C, hein !
Clair que si ça n'est même pas respecté, ça n'a pas d'intérêt.
Merci.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Stephane Dupille <sdupille+news@teaser.fr> wrote:
Forcément, pourtant, l'idée de (t)csh n'était-elle pas de s'inspirer du
c ?
En théorie oui, mais il est particulièrement incohérent.
Rhooohhhhh :-D
Par exemple, pour créer une variable du shell :
fooºr
Ah vi...
Pour créer une variable d'env :
setenv foo bar
Dans un cas il faut un =, dans l'autre, non.
Ah oui, pas logique, effectivement, je suis d'accord.
Dans un Bourne Shell, c'est beaucoup plus cohérents, plus limpide.
Ben, moi, j'ai du mal pourtant, mais il faut dire que je me plonge dans
le truc une fois tous les 6 mois, ça n'aide pas ;-)
Et si c'est pour avoir une syntaxe à la C, autant utiliser C, hein !
Clair que si ça n'est même pas respecté, ça n'a pas d'intérêt.
Merci.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Forcément, pourtant, l'idée de (t)csh n'était-elle pas de s'inspirer du c ?
En théorie oui, mais il est particulièrement incohérent.
Rhooohhhhh :-D
Par exemple, pour créer une variable du shell : fooºr
Ah vi...
Pour créer une variable d'env : setenv foo bar Dans un cas il faut un =, dans l'autre, non.
Ah oui, pas logique, effectivement, je suis d'accord.
Dans un Bourne Shell, c'est beaucoup plus cohérents, plus limpide.
Ben, moi, j'ai du mal pourtant, mais il faut dire que je me plonge dans le truc une fois tous les 6 mois, ça n'aide pas ;-)
Et si c'est pour avoir une syntaxe à la C, autant utiliser C, hein !
Clair que si ça n'est même pas respecté, ça n'a pas d'intérêt.
Merci.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Patrick Stadelmann
In article <1gl8r4k.1rp1kup1qr70lcN%, (Laurent Pertois) wrote:
Stephane Dupille <sdupille+ wrote:
Forcément, pourtant, l'idée de (t)csh n'était-elle pas de s'inspirer du c ?
En théorie oui, mais il est particulièrement incohérent.
Rhooohhhhh :-D
Par exemple, pour créer une variable du shell : fooºr
Ah vi...
Pour créer une variable d'env : setenv foo bar Dans un cas il faut un =, dans l'autre, non.
Ah oui, pas logique, effectivement, je suis d'accord.
Ben non, dans le 1er cas il n'y a pas de commande donc c'est a=b. Dans le second il y a une commande avec 2 paramètres, pas besoin du signe = donc. C'est comme en C :
a = 3;
mais
#define A 3
Patrick -- Patrick Stadelmann
In article <1gl8r4k.1rp1kup1qr70lcN%laurent.pertois@alussinan.org>,
laurent.pertois@alussinan.org (Laurent Pertois) wrote:
Stephane Dupille <sdupille+news@teaser.fr> wrote:
Forcément, pourtant, l'idée de (t)csh n'était-elle pas de s'inspirer du
c ?
En théorie oui, mais il est particulièrement incohérent.
Rhooohhhhh :-D
Par exemple, pour créer une variable du shell :
fooºr
Ah vi...
Pour créer une variable d'env :
setenv foo bar
Dans un cas il faut un =, dans l'autre, non.
Ah oui, pas logique, effectivement, je suis d'accord.
Ben non, dans le 1er cas il n'y a pas de commande donc c'est a=b. Dans
le second il y a une commande avec 2 paramètres, pas besoin du signe =
donc. C'est comme en C :
a = 3;
mais
#define A 3
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
In article <1gl8r4k.1rp1kup1qr70lcN%, (Laurent Pertois) wrote:
Stephane Dupille <sdupille+ wrote:
Forcément, pourtant, l'idée de (t)csh n'était-elle pas de s'inspirer du c ?
En théorie oui, mais il est particulièrement incohérent.
Rhooohhhhh :-D
Par exemple, pour créer une variable du shell : fooºr
Ah vi...
Pour créer une variable d'env : setenv foo bar Dans un cas il faut un =, dans l'autre, non.
Ah oui, pas logique, effectivement, je suis d'accord.
Ben non, dans le 1er cas il n'y a pas de commande donc c'est a=b. Dans le second il y a une commande avec 2 paramètres, pas besoin du signe = donc. C'est comme en C :
a = 3;
mais
#define A 3
Patrick -- Patrick Stadelmann
Stephane Dupille
En théorie oui, mais il est particulièrement incohérent. Rhooohhhhh :-D
Y'a pas que moi que le dit, hein. Et puis j'ai appris unix avec tcsh, puis bash pendant ma période Linux, puis maintenant zsh (je suis dans ma période BSD et Mac OS).
Dans un Bourne Shell, c'est beaucoup plus cohérents, plus limpide. Ben, moi, j'ai du mal pourtant, mais il faut dire que je me plonge dans
le truc une fois tous les 6 mois, ça n'aide pas ;-)
C'est clair qu'il faut en avoir l'usage. Si c'est pour juste taper les tips qui sont publiés dans les magazine, autant garder celui par défaut (mais je recommande quand même au moins de passer à bash).
Et si c'est pour avoir une syntaxe à la C, autant utiliser C, hein ! Clair que si ça n'est même pas respecté, ça n'a pas d'intérêt.
C'est surtout une bêtise sans nom : le C est un langage de prog système, et un shell, c'est une interface au système. Ça n'a rien à voir. C'est comme les shell Lisp, c'est rigolo, ça peut être pratique pour faire des scripts, mais à utiliser c'est la plaie.
Merci.
Ah mais de rien !
-- C'est impossible que la majorité ait voté pour détruire le frjv sans créer un ou des autres NG. C'est incompréhensible... -+- AS in GNU : et pis d'abord les dinosaures y existent même pas -+-
En théorie oui, mais il est particulièrement incohérent.
Rhooohhhhh :-D
Y'a pas que moi que le dit, hein. Et puis j'ai appris unix avec
tcsh, puis bash pendant ma période Linux, puis maintenant zsh (je suis
dans ma période BSD et Mac OS).
Dans un Bourne Shell, c'est beaucoup plus cohérents, plus limpide.
Ben, moi, j'ai du mal pourtant, mais il faut dire que je me plonge dans
le truc une fois tous les 6 mois, ça n'aide pas ;-)
C'est clair qu'il faut en avoir l'usage. Si c'est pour juste taper
les tips qui sont publiés dans les magazine, autant garder celui par
défaut (mais je recommande quand même au moins de passer à bash).
Et si c'est pour avoir une syntaxe à la C, autant utiliser C, hein !
Clair que si ça n'est même pas respecté, ça n'a pas d'intérêt.
C'est surtout une bêtise sans nom : le C est un langage de prog
système, et un shell, c'est une interface au système. Ça n'a rien à
voir. C'est comme les shell Lisp, c'est rigolo, ça peut être pratique
pour faire des scripts, mais à utiliser c'est la plaie.
Merci.
Ah mais de rien !
--
C'est impossible que la majorité ait voté pour détruire le frjv sans
créer un ou des autres NG. C'est incompréhensible...
-+- AS in GNU : et pis d'abord les dinosaures y existent même pas -+-
En théorie oui, mais il est particulièrement incohérent. Rhooohhhhh :-D
Y'a pas que moi que le dit, hein. Et puis j'ai appris unix avec tcsh, puis bash pendant ma période Linux, puis maintenant zsh (je suis dans ma période BSD et Mac OS).
Dans un Bourne Shell, c'est beaucoup plus cohérents, plus limpide. Ben, moi, j'ai du mal pourtant, mais il faut dire que je me plonge dans
le truc une fois tous les 6 mois, ça n'aide pas ;-)
C'est clair qu'il faut en avoir l'usage. Si c'est pour juste taper les tips qui sont publiés dans les magazine, autant garder celui par défaut (mais je recommande quand même au moins de passer à bash).
Et si c'est pour avoir une syntaxe à la C, autant utiliser C, hein ! Clair que si ça n'est même pas respecté, ça n'a pas d'intérêt.
C'est surtout une bêtise sans nom : le C est un langage de prog système, et un shell, c'est une interface au système. Ça n'a rien à voir. C'est comme les shell Lisp, c'est rigolo, ça peut être pratique pour faire des scripts, mais à utiliser c'est la plaie.
Merci.
Ah mais de rien !
-- C'est impossible que la majorité ait voté pour détruire le frjv sans créer un ou des autres NG. C'est incompréhensible... -+- AS in GNU : et pis d'abord les dinosaures y existent même pas -+-
yvon.thoravalNO-SPAM
Nicolas MICHEL wrote:
Mais si tu veux savoir quel shell utiliser, prends sh pour les scripts et zsh ou bash en interactif.
quel est le mieux adapté pour les accents en UTF-8 ? j'utilise zsh mais les majuscules accentuées ne passent pas, les minuscules si...
j'ai besoin des accents uniquement pour certains arguments, par exemple, recherche d'un texte dans un fichier. -- yt
Nicolas MICHEL <Nicolas.MICHEL@BonBon.net> wrote:
Mais si tu veux savoir quel shell utiliser, prends sh pour les scripts
et zsh ou bash en interactif.
quel est le mieux adapté pour les accents en UTF-8 ?
j'utilise zsh mais les majuscules accentuées ne passent pas, les
minuscules si...
j'ai besoin des accents uniquement pour certains arguments, par exemple,
recherche d'un texte dans un fichier.
--
yt
Mais si tu veux savoir quel shell utiliser, prends sh pour les scripts et zsh ou bash en interactif.
quel est le mieux adapté pour les accents en UTF-8 ? j'utilise zsh mais les majuscules accentuées ne passent pas, les minuscules si...
j'ai besoin des accents uniquement pour certains arguments, par exemple, recherche d'un texte dans un fichier. -- yt
Stephane Dupille
Ah oui, pas logique, effectivement, je suis d'accord. Ben non, dans le 1er cas il n'y a pas de commande donc c'est a=b. Dans
le second il y a une commande avec 2 paramètres, pas besoin du signe > donc. C'est comme en C : a = 3; mais #define A 3
Sauf que le parallèle avec le C est foireux. Déjà, #define n'est pas une commande du C, mais une directive de cpp. De plus, cela ne définit pas une variable, mais une macro (ou une constante).
En C, la différence entre #define et une variable est claire : l'un est un élement du langage, pas l'autre, et ont des usages différents.
Alors que la différence entre une variable et une var d'env ne tient que sur un aspect : l'héritage aux process fils. Raison pour laquelle tous les autres shells ne font pas le distingo : on crée toutes les variables de la même façon, et on décide ensuite de les exporter ou non (voir de le faire en une seule et même étape : "export fooºz").
-- Ce qu'il y a de cruel, avec ces forums, c'est qu'ils nous confrontent impitoyablement aux insoutenables limites de l'intelligence humaine. On ne saurait être humaniste sans en concevoir une profonde angoisse. -+-DL in <http://www.le-gnu.net>: L'insoutenable lourdeur du neuneu -+-
Ah oui, pas logique, effectivement, je suis d'accord.
Ben non, dans le 1er cas il n'y a pas de commande donc c'est a=b. Dans
le second il y a une commande avec 2 paramètres, pas besoin du signe > donc. C'est comme en C :
a = 3;
mais
#define A 3
Sauf que le parallèle avec le C est foireux. Déjà, #define n'est pas
une commande du C, mais une directive de cpp. De plus, cela ne définit
pas une variable, mais une macro (ou une constante).
En C, la différence entre #define et une variable est claire : l'un
est un élement du langage, pas l'autre, et ont des usages différents.
Alors que la différence entre une variable et une var d'env ne tient
que sur un aspect : l'héritage aux process fils. Raison pour laquelle
tous les autres shells ne font pas le distingo : on crée toutes les
variables de la même façon, et on décide ensuite de les exporter ou
non (voir de le faire en une seule et même étape : "export fooºz").
--
Ce qu'il y a de cruel, avec ces forums, c'est qu'ils nous confrontent
impitoyablement aux insoutenables limites de l'intelligence humaine. On
ne saurait être humaniste sans en concevoir une profonde angoisse.
-+-DL in <http://www.le-gnu.net>: L'insoutenable lourdeur du neuneu -+-
Ah oui, pas logique, effectivement, je suis d'accord. Ben non, dans le 1er cas il n'y a pas de commande donc c'est a=b. Dans
le second il y a une commande avec 2 paramètres, pas besoin du signe > donc. C'est comme en C : a = 3; mais #define A 3
Sauf que le parallèle avec le C est foireux. Déjà, #define n'est pas une commande du C, mais une directive de cpp. De plus, cela ne définit pas une variable, mais une macro (ou une constante).
En C, la différence entre #define et une variable est claire : l'un est un élement du langage, pas l'autre, et ont des usages différents.
Alors que la différence entre une variable et une var d'env ne tient que sur un aspect : l'héritage aux process fils. Raison pour laquelle tous les autres shells ne font pas le distingo : on crée toutes les variables de la même façon, et on décide ensuite de les exporter ou non (voir de le faire en une seule et même étape : "export fooºz").
-- Ce qu'il y a de cruel, avec ces forums, c'est qu'ils nous confrontent impitoyablement aux insoutenables limites de l'intelligence humaine. On ne saurait être humaniste sans en concevoir une profonde angoisse. -+-DL in <http://www.le-gnu.net>: L'insoutenable lourdeur du neuneu -+-
