16:56-> ~/programmation/perl% ./prog1.pl un nombre entier 3 16:56-> ~/programmation/perl%
la deuxième ligne ne s'affiche pas :(
Bonjour, chez moi tout fonctionne.
PS : là ce n'est pas grave, mais n'oubliez pas d'utiliser use strict et use warnings...
-- "Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce que je veux !" "The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers." (Bill Gates, The Road Ahead)
16:56->serge@amon ~/programmation/perl% ./prog1.pl
un nombre entier 3
16:56->serge@amon ~/programmation/perl%
la deuxième ligne ne s'affiche pas :(
Bonjour, chez moi tout fonctionne.
PS : là ce n'est pas grave, mais n'oubliez pas d'utiliser use strict et
use warnings...
--
"Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce
que je veux !"
"The obvious mathematical breakthrough would be development of an easy
way to factor large prime numbers." (Bill Gates, The Road Ahead)
16:56-> ~/programmation/perl% ./prog1.pl un nombre entier 3 16:56-> ~/programmation/perl%
la deuxième ligne ne s'affiche pas :(
Bonjour, chez moi tout fonctionne.
PS : là ce n'est pas grave, mais n'oubliez pas d'utiliser use strict et use warnings...
-- "Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce que je veux !" "The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers." (Bill Gates, The Road Ahead)
Thomas vO
bonjour,
À (at) Wed, 11 May 2005 17:09:35 +0200, Sergio nous disait (told us):
Bonjour,
Depuis le temps que je me le dis, je me lance enfin dans perl et me voilà coincé après mon premier programme :-( :
16:56-> ~/programmation/perl% ./prog1.pl un nombre entier 3 16:56-> ~/programmation/perl%
la deuxième ligne ne s'affiche pas :(
En fait, je pense qu'elle s'affiche bien mais elle doit être cachée par votre prompt (si c'est bien cela je vous conseille alors de modifier la définition de votre prompt pour éviter de revenir en début de ligne...).
Pour vous en persuader, essayez la commande suivante :
% ./prog1.pl | od -xc
ou alors modifier votre dernière instruction en :
print $liste[0],$liste[3],$liste[4],"n";
Autre possibilité, vous êtes sur un système qui ne vide pas les buffers de sortie standard d'un programme qui se termine... Personnellement, je n'ai jamais vu de tels systèmes. Ce défaut peut aussi être dû à un mauvais choix de bibliothèque d'I/O lors de l'installation de perl. Quelle version de perl ? Configuré par qui et comment ? Sur quel OS ? (un appel à 'perl -V' devrait vous dire tout cela).
PS: on peut déjà être sûr que $liste[0] est affiché puisque il y a bien un passage à la ligne après l'affichage du 3 !
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
À (at) Wed, 11 May 2005 17:09:35 +0200,
Sergio <serge.sauton@ac-amiens.fr> écrivait (wrote):
Depuis le temps que je me le dis, je me lance enfin dans perl et me voilà
coincé après mon premier programme :-( :
16:56->serge@amon ~/programmation/perl% ./prog1.pl
un nombre entier 3
16:56->serge@amon ~/programmation/perl%
la deuxième ligne ne s'affiche pas :(
En fait, je pense qu'elle s'affiche bien mais elle doit être cachée par votre
prompt (si c'est bien cela je vous conseille alors de modifier la définition
de votre prompt pour éviter de revenir en début de ligne...).
Pour vous en persuader, essayez la commande suivante :
% ./prog1.pl | od -xc
ou alors modifier votre dernière instruction en :
print $liste[0],$liste[3],$liste[4],"n";
Autre possibilité, vous êtes sur un système qui ne vide pas les buffers de
sortie standard d'un programme qui se termine... Personnellement, je n'ai
jamais vu de tels systèmes. Ce défaut peut aussi être dû à un mauvais choix de
bibliothèque d'I/O lors de l'installation de perl. Quelle version de perl ?
Configuré par qui et comment ? Sur quel OS ? (un appel à 'perl -V' devrait
vous dire tout cela).
PS: on peut déjà être sûr que $liste[0] est affiché puisque il y a bien un
passage à la ligne après l'affichage du 3 !
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>
16:56-> ~/programmation/perl% ./prog1.pl un nombre entier 3 16:56-> ~/programmation/perl%
la deuxième ligne ne s'affiche pas :(
En fait, je pense qu'elle s'affiche bien mais elle doit être cachée par votre prompt (si c'est bien cela je vous conseille alors de modifier la définition de votre prompt pour éviter de revenir en début de ligne...).
Pour vous en persuader, essayez la commande suivante :
% ./prog1.pl | od -xc
ou alors modifier votre dernière instruction en :
print $liste[0],$liste[3],$liste[4],"n";
Autre possibilité, vous êtes sur un système qui ne vide pas les buffers de sortie standard d'un programme qui se termine... Personnellement, je n'ai jamais vu de tels systèmes. Ce défaut peut aussi être dû à un mauvais choix de bibliothèque d'I/O lors de l'installation de perl. Quelle version de perl ? Configuré par qui et comment ? Sur quel OS ? (un appel à 'perl -V' devrait vous dire tout cela).
PS: on peut déjà être sûr que $liste[0] est affiché puisque il y a bien un passage à la ligne après l'affichage du 3 !
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
Sergio
Bonjour, chez moi tout fonctionne.
Ah ???
J'ai "simplifié" en :
#!/usr/bin/perl print "1"; print "2";
et rien ne s'affiche à l'exécution.
Si je modifie en :
#!/usr/bin/perl print "1n"; print "2";
1 s'affiche.
Et si je change en :
#!/usr/bin/perl
print "1n"; print "2n";
1 2
s'affiche.
PS : là ce n'est pas grave, mais n'oubliez pas d'utiliser use strict et use warnings...
OK, merci.
-- Serge
Bonjour, chez moi tout fonctionne.
Ah ???
J'ai "simplifié" en :
#!/usr/bin/perl
print "1";
print "2";
et rien ne s'affiche à l'exécution.
Si je modifie en :
#!/usr/bin/perl
print "1n";
print "2";
1 s'affiche.
Et si je change en :
#!/usr/bin/perl
print "1n";
print "2n";
1
2
s'affiche.
PS : là ce n'est pas grave, mais n'oubliez pas d'utiliser use strict et
use warnings...
Si, mais le prompt du shell le cache. Ajouter un retour à la ligne à la fin.
Sergio
En fait, je pense qu'elle s'affiche bien mais elle doit être cachée par votre prompt
Oui, c'est bien ça car si je double la commande, la première s'affich e !
si c'est bien cela je vous conseille alors de modifier la définition de votre prompt pour éviter de revenir en début de ligne...).
J'utilise zsh. J'imagine que c'est dans le fichier .zshrc Faut-il ajouter quelque chose à la fin de la définition de la variabl e PS1 ou s'agit-il d'autre chose ?
Sur quel OS ? (un appel à 'perl -V' devrait vous dire tout cela).
23:24-> ~% perl -v
This is perl, v5.8.4 built for i386-linux-thread-multi
Merci beaucoup à tous pour l'aide.
-- Serge
En fait, je pense qu'elle s'affiche bien mais elle doit être cachée par votre
prompt
Oui, c'est bien ça car si je double la commande, la première s'affich e !
si c'est bien cela je vous conseille alors de modifier la définition
de votre prompt pour éviter de revenir en début de ligne...).
J'utilise zsh. J'imagine que c'est dans le fichier .zshrc
Faut-il ajouter quelque chose à la fin de la définition de la variabl e
PS1 ou s'agit-il d'autre chose ?
Sur quel OS ? (un appel à 'perl -V' devrait
vous dire tout cela).
23:24->serge@amon ~% perl -v
This is perl, v5.8.4 built for i386-linux-thread-multi
En fait, je pense qu'elle s'affiche bien mais elle doit être cachée par votre prompt
Oui, c'est bien ça car si je double la commande, la première s'affich e !
si c'est bien cela je vous conseille alors de modifier la définition de votre prompt pour éviter de revenir en début de ligne...).
J'utilise zsh. J'imagine que c'est dans le fichier .zshrc Faut-il ajouter quelque chose à la fin de la définition de la variabl e PS1 ou s'agit-il d'autre chose ?
Sur quel OS ? (un appel à 'perl -V' devrait vous dire tout cela).
23:24-> ~% perl -v
This is perl, v5.8.4 built for i386-linux-thread-multi
Merci beaucoup à tous pour l'aide.
-- Serge
Nicolas George
Sergio wrote in message <42827885$0$24328$:
J'utilise zsh. J'imagine que c'est dans le fichier .zshrc Faut-il ajouter quelque chose à la fin de la définition de la variable PS1 ou s'agit-il d'autre chose ?
Il y a l'option prompt_cr, qu'il est possible de désactiver. Mais ce n'est pas forcément une bonne idée pour diverses raisons que je n'ai pas le temps d'expliquer.
De toutes façons, un programme qui affiche du texte et ne le termine pas par un n est buggé, il faut le corriger, pas faire du bugware dans le shell pour contourner.
Sergio wrote in message <42827885$0$24328$626a14ce@news.free.fr>:
J'utilise zsh. J'imagine que c'est dans le fichier .zshrc
Faut-il ajouter quelque chose à la fin de la définition de la variable
PS1 ou s'agit-il d'autre chose ?
Il y a l'option prompt_cr, qu'il est possible de désactiver. Mais ce n'est
pas forcément une bonne idée pour diverses raisons que je n'ai pas le temps
d'expliquer.
De toutes façons, un programme qui affiche du texte et ne le termine pas par
un n est buggé, il faut le corriger, pas faire du bugware dans le shell
pour contourner.
J'utilise zsh. J'imagine que c'est dans le fichier .zshrc Faut-il ajouter quelque chose à la fin de la définition de la variable PS1 ou s'agit-il d'autre chose ?
Il y a l'option prompt_cr, qu'il est possible de désactiver. Mais ce n'est pas forcément une bonne idée pour diverses raisons que je n'ai pas le temps d'expliquer.
De toutes façons, un programme qui affiche du texte et ne le termine pas par un n est buggé, il faut le corriger, pas faire du bugware dans le shell pour contourner.
Paul Gaborit
À (at) Wed, 11 May 2005 22:01:15 +0000 (UTC), Nicolas George <nicolas$ écrivait (wrote):
Il y a l'option prompt_cr, qu'il est possible de désactiver. Mais ce n'est pas forcément une bonne idée pour diverses raisons que je n'ai pas le temps d'expliquer.
C'est pourtant bien là qu'est le bug puisque cette option est activée par défaut. J'aimerai bien connaître vos "diverses raisons"...
De toutes façons, un programme qui affiche du texte et ne le termine pas par un n est buggé, il faut le corriger, pas faire du bugware dans le shell pour contourner.
Ah ? Alors la commande 'cat' (par exemple) doit être bugguée puisqu'elle n'ajoute pas de n à la fin d'un fichier qui n'en contient pas...
Un prompt qui cache les messages affichés (même si ils n'ont pas de fin de ligne) est un vrai bug ! On peut même considérer cela comme un trou de sécurité...
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
À (at) Wed, 11 May 2005 22:01:15 +0000 (UTC),
Nicolas George <nicolas$george@salle-s.org> écrivait (wrote):
Il y a l'option prompt_cr, qu'il est possible de désactiver. Mais ce n'est
pas forcément une bonne idée pour diverses raisons que je n'ai pas le temps
d'expliquer.
C'est pourtant bien là qu'est le bug puisque cette option est activée par
défaut. J'aimerai bien connaître vos "diverses raisons"...
De toutes façons, un programme qui affiche du texte et ne le termine pas par
un n est buggé, il faut le corriger, pas faire du bugware dans le shell
pour contourner.
Ah ? Alors la commande 'cat' (par exemple) doit être bugguée puisqu'elle
n'ajoute pas de n à la fin d'un fichier qui n'en contient pas...
Un prompt qui cache les messages affichés (même si ils n'ont pas de fin de
ligne) est un vrai bug ! On peut même considérer cela comme un trou de
sécurité...
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>
À (at) Wed, 11 May 2005 22:01:15 +0000 (UTC), Nicolas George <nicolas$ écrivait (wrote):
Il y a l'option prompt_cr, qu'il est possible de désactiver. Mais ce n'est pas forcément une bonne idée pour diverses raisons que je n'ai pas le temps d'expliquer.
C'est pourtant bien là qu'est le bug puisque cette option est activée par défaut. J'aimerai bien connaître vos "diverses raisons"...
De toutes façons, un programme qui affiche du texte et ne le termine pas par un n est buggé, il faut le corriger, pas faire du bugware dans le shell pour contourner.
Ah ? Alors la commande 'cat' (par exemple) doit être bugguée puisqu'elle n'ajoute pas de n à la fin d'un fichier qui n'en contient pas...
Un prompt qui cache les messages affichés (même si ils n'ont pas de fin de ligne) est un vrai bug ! On peut même considérer cela comme un trou de sécurité...
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
Nicolas George
Paul Gaborit wrote in message :
C'est pourtant bien là qu'est le bug puisque cette option est activée par défaut. J'aimerai bien connaître vos "diverses raisons"...
zsh, comme beaucoup de shells modernes, est doté d'un éditeur de ligne évolué. Une application n'a aucun moyen standard de s'enquérir de ce qu'il y a déjà dans le terminal. Dans le cas d'un éditeur de ligne, ça veut dire qu'il n'y a pas moyen de recaler le curseur correctement après des affichages un peu complexes (édition multiligne ou menu de complétion). En pratique, ça donne un affichage extrémement confus et déroutant.
Ah ? Alors la commande 'cat' (par exemple) doit être bugguée puisqu'elle n'ajoute pas de n à la fin d'un fichier qui n'en contient pas...
Rien ne dit que ce que cat affiche est du texte, argument nul et non avenu donc. En revanche, toutes les versions de cat que je connais, quand elles affichent du texte (typiquement des messages d'erreur), le terminent par n.
Paul Gaborit wrote in message <r7br7g4wrj.fsf@iena.enstimac.fr>:
C'est pourtant bien là qu'est le bug puisque cette option est activée par
défaut. J'aimerai bien connaître vos "diverses raisons"...
zsh, comme beaucoup de shells modernes, est doté d'un éditeur de ligne
évolué. Une application n'a aucun moyen standard de s'enquérir de ce qu'il y
a déjà dans le terminal. Dans le cas d'un éditeur de ligne, ça veut dire
qu'il n'y a pas moyen de recaler le curseur correctement après des
affichages un peu complexes (édition multiligne ou menu de complétion). En
pratique, ça donne un affichage extrémement confus et déroutant.
Ah ? Alors la commande 'cat' (par exemple) doit être bugguée puisqu'elle
n'ajoute pas de n à la fin d'un fichier qui n'en contient pas...
Rien ne dit que ce que cat affiche est du texte, argument nul et non avenu
donc. En revanche, toutes les versions de cat que je connais, quand elles
affichent du texte (typiquement des messages d'erreur), le terminent par n.
C'est pourtant bien là qu'est le bug puisque cette option est activée par défaut. J'aimerai bien connaître vos "diverses raisons"...
zsh, comme beaucoup de shells modernes, est doté d'un éditeur de ligne évolué. Une application n'a aucun moyen standard de s'enquérir de ce qu'il y a déjà dans le terminal. Dans le cas d'un éditeur de ligne, ça veut dire qu'il n'y a pas moyen de recaler le curseur correctement après des affichages un peu complexes (édition multiligne ou menu de complétion). En pratique, ça donne un affichage extrémement confus et déroutant.
Ah ? Alors la commande 'cat' (par exemple) doit être bugguée puisqu'elle n'ajoute pas de n à la fin d'un fichier qui n'en contient pas...
Rien ne dit que ce que cat affiche est du texte, argument nul et non avenu donc. En revanche, toutes les versions de cat que je connais, quand elles affichent du texte (typiquement des messages d'erreur), le terminent par n.
Paul Gaborit
À (at) Thu, 12 May 2005 15:48:02 +0000 (UTC), Nicolas George <nicolas$ écrivait (wrote):
Paul Gaborit wrote in message :
C'est pourtant bien là qu'est le bug puisque cette option est activée par défaut. J'aimerai bien connaître vos "diverses raisons"...
zsh, comme beaucoup de shells modernes, est doté d'un éditeur de ligne évolué. Une application n'a aucun moyen standard de s'enquérir de ce qu'il y a déjà dans le terminal. Dans le cas d'un éditeur de ligne, ça veut dire qu'il n'y a pas moyen de recaler le curseur correctement après des affichages un peu complexes (édition multiligne ou menu de complétion). En pratique, ça donne un affichage extrémement confus et déroutant.
Donc pour une simple facilité d'édition (qui reste active quoiqu'il arrive et qui n'est cassée que dans les rares cas où une commande ne terminerait pas ses affichages par une fin de ligne), vous préférez parfois ne pas voir ce qui a été affiché.
Pourtant lorsque cela arrive, on s'en rend compte facilement («Tiens mon prompt n'est pas au début de ligne») et un simple <Return> ou <Ctrl-C> suffit à tout remettre d'aplomb.
De plus cela permet au développeur de voir ses bugs : « Tiens, j'ai du oublié de mettre un n!» plutôt que « Mais pourquoi rien ne s'affiche ?».
Ah ? Alors la commande 'cat' (par exemple) doit être bugguée puisqu'elle n'ajoute pas de n à la fin d'un fichier qui n'en contient pas...
Rien ne dit que ce que cat affiche est du texte, argument nul et non avenu donc. En revanche, toutes les versions de cat que je connais, quand elles affichent du texte (typiquement des messages d'erreur), le terminent par n.
Lorsqu'on développe, on ne peut pas être sûr du moment où le programme plante. Par ailleurs, comme vous dites, rien ne dit que ce qui est affiché est du texte... et pourtant c'est certainement utile puisque c'est affiché ;-)
Autre situation (purement imaginaire), supposez que je vous envoie un petit script sh pour résoudre un problème quelconque. Avant de l'exécuter, prudent mais un peu pressé, vous faites un simple 'cat script' pour en vérifier le contenu (un script, c'est bien un fichier texte, non ?). Que des commandes tout à fait correctes... Vous l'exécutez et POUF : plus rien dans vos répertoires !
Mon script se termine tout simplement par une ligne "rm -fr ~" sans fin de ligne, ligne que j'avais bien évidemment oubliée accidentellement. Votre commande 'cat' vous a bien affiché cette dernière ligne mais votre shell vous la cache.
Moi j'appelle cela un bug !
Maintenant, vous faites comme vous voulez...
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
À (at) Thu, 12 May 2005 15:48:02 +0000 (UTC),
Nicolas George <nicolas$george@salle-s.org> écrivait (wrote):
Paul Gaborit wrote in message <r7br7g4wrj.fsf@iena.enstimac.fr>:
C'est pourtant bien là qu'est le bug puisque cette option est activée par
défaut. J'aimerai bien connaître vos "diverses raisons"...
zsh, comme beaucoup de shells modernes, est doté d'un éditeur de ligne
évolué. Une application n'a aucun moyen standard de s'enquérir de ce qu'il y
a déjà dans le terminal. Dans le cas d'un éditeur de ligne, ça veut dire
qu'il n'y a pas moyen de recaler le curseur correctement après des
affichages un peu complexes (édition multiligne ou menu de complétion). En
pratique, ça donne un affichage extrémement confus et déroutant.
Donc pour une simple facilité d'édition (qui reste active quoiqu'il arrive et
qui n'est cassée que dans les rares cas où une commande ne terminerait pas ses
affichages par une fin de ligne), vous préférez parfois ne pas voir ce qui a
été affiché.
Pourtant lorsque cela arrive, on s'en rend compte facilement («Tiens mon
prompt n'est pas au début de ligne») et un simple <Return> ou <Ctrl-C> suffit
à tout remettre d'aplomb.
De plus cela permet au développeur de voir ses bugs : « Tiens, j'ai du oublié
de mettre un n!» plutôt que « Mais pourquoi rien ne s'affiche ?».
Ah ? Alors la commande 'cat' (par exemple) doit être bugguée puisqu'elle
n'ajoute pas de n à la fin d'un fichier qui n'en contient pas...
Rien ne dit que ce que cat affiche est du texte, argument nul et non avenu
donc. En revanche, toutes les versions de cat que je connais, quand elles
affichent du texte (typiquement des messages d'erreur), le terminent par n.
Lorsqu'on développe, on ne peut pas être sûr du moment où le programme
plante. Par ailleurs, comme vous dites, rien ne dit que ce qui est affiché est
du texte... et pourtant c'est certainement utile puisque c'est affiché ;-)
Autre situation (purement imaginaire), supposez que je vous envoie un petit
script sh pour résoudre un problème quelconque. Avant de l'exécuter, prudent
mais un peu pressé, vous faites un simple 'cat script' pour en vérifier le
contenu (un script, c'est bien un fichier texte, non ?). Que des commandes
tout à fait correctes... Vous l'exécutez et POUF : plus rien dans vos
répertoires !
Mon script se termine tout simplement par une ligne "rm -fr ~" sans fin de
ligne, ligne que j'avais bien évidemment oubliée accidentellement. Votre
commande 'cat' vous a bien affiché cette dernière ligne mais votre shell vous
la cache.
Moi j'appelle cela un bug !
Maintenant, vous faites comme vous voulez...
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>
À (at) Thu, 12 May 2005 15:48:02 +0000 (UTC), Nicolas George <nicolas$ écrivait (wrote):
Paul Gaborit wrote in message :
C'est pourtant bien là qu'est le bug puisque cette option est activée par défaut. J'aimerai bien connaître vos "diverses raisons"...
zsh, comme beaucoup de shells modernes, est doté d'un éditeur de ligne évolué. Une application n'a aucun moyen standard de s'enquérir de ce qu'il y a déjà dans le terminal. Dans le cas d'un éditeur de ligne, ça veut dire qu'il n'y a pas moyen de recaler le curseur correctement après des affichages un peu complexes (édition multiligne ou menu de complétion). En pratique, ça donne un affichage extrémement confus et déroutant.
Donc pour une simple facilité d'édition (qui reste active quoiqu'il arrive et qui n'est cassée que dans les rares cas où une commande ne terminerait pas ses affichages par une fin de ligne), vous préférez parfois ne pas voir ce qui a été affiché.
Pourtant lorsque cela arrive, on s'en rend compte facilement («Tiens mon prompt n'est pas au début de ligne») et un simple <Return> ou <Ctrl-C> suffit à tout remettre d'aplomb.
De plus cela permet au développeur de voir ses bugs : « Tiens, j'ai du oublié de mettre un n!» plutôt que « Mais pourquoi rien ne s'affiche ?».
Ah ? Alors la commande 'cat' (par exemple) doit être bugguée puisqu'elle n'ajoute pas de n à la fin d'un fichier qui n'en contient pas...
Rien ne dit que ce que cat affiche est du texte, argument nul et non avenu donc. En revanche, toutes les versions de cat que je connais, quand elles affichent du texte (typiquement des messages d'erreur), le terminent par n.
Lorsqu'on développe, on ne peut pas être sûr du moment où le programme plante. Par ailleurs, comme vous dites, rien ne dit que ce qui est affiché est du texte... et pourtant c'est certainement utile puisque c'est affiché ;-)
Autre situation (purement imaginaire), supposez que je vous envoie un petit script sh pour résoudre un problème quelconque. Avant de l'exécuter, prudent mais un peu pressé, vous faites un simple 'cat script' pour en vérifier le contenu (un script, c'est bien un fichier texte, non ?). Que des commandes tout à fait correctes... Vous l'exécutez et POUF : plus rien dans vos répertoires !
Mon script se termine tout simplement par une ligne "rm -fr ~" sans fin de ligne, ligne que j'avais bien évidemment oubliée accidentellement. Votre commande 'cat' vous a bien affiché cette dernière ligne mais votre shell vous la cache.
Moi j'appelle cela un bug !
Maintenant, vous faites comme vous voulez...
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
