je suis en train d'=E9crire (laborieusement) un script bash, et j'ai un pro=
bl=E8me=20
de syntaxe dans les boucles if :
if [ -d $movie ]
then
...
if [ "$PAYSLOT_MOVIE" -ge "7" ]
then
...
else if [ "$PAYSLOT_MOVIE" -eq "1"] && [ "$PAYSLOT_MOVIE" -eq "3"]=
=20
then
...
fi
else
....
fi
quand j'execute, ca me dit " syntax error near unexpected token `else' " a =
la=20
ligne du second else (le dernier a la fin). Pourtant il me semble qu'on peu=
t=20
imbriquer des boucles ? Un exemple en est m=EAme donn=E9 a la page 123=A0du=
ABS=20
guide.
Quelqu'un a une id=E9e ?
Merci !
Jeremy
=2D-=20
=2D-----
Linux Registered User #317862
You want to use GNU/Linux or Windows ?
=2D You want to spend time or money ?
Why is Microsoft raising prices on you? Because they can !
=2D To take that power away from them, use Linux !
On Sat, Sep 04, 2004 at 11:04:03AM +0200, Jeremy Monnet wrote:
Passe, passe le oinje ! :-p
Ça marche aussi avec les poissons rouges, mais ça prend plus de temps.
Non sans rire c'est vrai qu même quand on recherche sur google, on recherche souvent juste 2 ou 3 mots qui semblent pertinents .... Et quand on doit expliquer son problème on y passe beaucoup plus de temps, et donc on trouve souvent d'autres mots clés, ou on s'ouvre à d'autres voies de recherches ...
Expliquer oblige aussi à reprendre le problème depuis le début, ce qui, en général, fait prendre un recul salutaire.
Pour ce qui est de remplacer "cat file | " par "sed file", est-ce que ca peut être considéré comme "plus propre", "plus ri goureux", "plus unixien", ou est-ce que c'est juste une vieille habitude de toujours faire "au plus juste" ?
En théorie c'est "plus efficace": dans "sed file", sed ouvre le fichier directement et lit le fichier; dans "cat file | sed", cat ouvre le fichier, le lit et le copie sur son stdout, le shell fait la plomberie et copie sur le stdin du sed. On se retrouve donc avec une copie intégrale du flux, qui est inutile.
Cela dit, j'avais fait quelques mesures (à rechercher dans les archives de la liste)), et la différence de performance n'était pas franchement convaincante. En fait, avec une VM suffisament sophistiquée qui sache faire du prêt de page, la différence ne devrait pratiquement plus exister (je ne sais pas si Linux sait faire du prêt de page; certains BSD le font).
En fait je veux juste des avis parce que je ne suis pas sur qu'il y ait une réponse ferme et définitive pour mettre tout le monde d'accord ?
Sans doute correct :-)
Y.
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
On Sat, Sep 04, 2004 at 11:04:03AM +0200, Jeremy Monnet wrote:
Passe, passe le oinje ! :-p
Ça marche aussi avec les poissons rouges, mais ça prend plus
de temps.
Non sans rire c'est vrai qu même quand on recherche sur google, on recherche
souvent juste 2 ou 3 mots qui semblent pertinents .... Et quand on doit
expliquer son problème on y passe beaucoup plus de temps, et donc on trouve
souvent d'autres mots clés, ou on s'ouvre à d'autres voies de recherches ...
Expliquer oblige aussi à reprendre le problème depuis le
début, ce qui, en général, fait prendre un recul salutaire.
Pour ce qui est de remplacer "cat file | " par "sed file", est-ce que ca peut
être considéré comme "plus propre", "plus ri goureux", "plus unixien", ou
est-ce que c'est juste une vieille habitude de toujours faire "au plus
juste" ?
En théorie c'est "plus efficace": dans "sed file", sed ouvre
le fichier directement et lit le fichier; dans "cat file |
sed", cat ouvre le fichier, le lit et le copie sur son
stdout, le shell fait la plomberie et copie sur le stdin du
sed. On se retrouve donc avec une copie intégrale du flux,
qui est inutile.
Cela dit, j'avais fait quelques mesures (à rechercher dans
les archives de la liste)), et la différence de performance
n'était pas franchement convaincante. En fait, avec une VM
suffisament sophistiquée qui sache faire du prêt de page, la
différence ne devrait pratiquement plus exister (je ne sais
pas si Linux sait faire du prêt de page; certains BSD le
font).
En fait je veux juste des avis parce que je ne suis pas
sur qu'il y ait une réponse ferme et définitive pour
mettre tout le monde d'accord ?
Sans doute correct :-)
Y.
--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
On Sat, Sep 04, 2004 at 11:04:03AM +0200, Jeremy Monnet wrote:
Passe, passe le oinje ! :-p
Ça marche aussi avec les poissons rouges, mais ça prend plus de temps.
Non sans rire c'est vrai qu même quand on recherche sur google, on recherche souvent juste 2 ou 3 mots qui semblent pertinents .... Et quand on doit expliquer son problème on y passe beaucoup plus de temps, et donc on trouve souvent d'autres mots clés, ou on s'ouvre à d'autres voies de recherches ...
Expliquer oblige aussi à reprendre le problème depuis le début, ce qui, en général, fait prendre un recul salutaire.
Pour ce qui est de remplacer "cat file | " par "sed file", est-ce que ca peut être considéré comme "plus propre", "plus ri goureux", "plus unixien", ou est-ce que c'est juste une vieille habitude de toujours faire "au plus juste" ?
En théorie c'est "plus efficace": dans "sed file", sed ouvre le fichier directement et lit le fichier; dans "cat file | sed", cat ouvre le fichier, le lit et le copie sur son stdout, le shell fait la plomberie et copie sur le stdin du sed. On se retrouve donc avec une copie intégrale du flux, qui est inutile.
Cela dit, j'avais fait quelques mesures (à rechercher dans les archives de la liste)), et la différence de performance n'était pas franchement convaincante. En fait, avec une VM suffisament sophistiquée qui sache faire du prêt de page, la différence ne devrait pratiquement plus exister (je ne sais pas si Linux sait faire du prêt de page; certains BSD le font).
En fait je veux juste des avis parce que je ne suis pas sur qu'il y ait une réponse ferme et définitive pour mettre tout le monde d'accord ?
Sans doute correct :-)
Y.
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
fra-duf-no-spam
Le 12665ième jour après Epoch, Yves Rutschle écrivait:
On Fri, Sep 03, 2004 at 10:46:38PM +0200, Jeremy Monnet wrote:
PS : pourquoi après avoir des heures, on trouve souvent une soluce 3 minutes après avoir posé la question ? PS2 : peut-être parce qu'on a réfléchi correctement a sa formulation entre temps ?
Correct, c'est pour ça qu'il est souvent utile d'expliquer le problème à son chat: on lui explique, et au milieu de l'explication on s'exclame "bon sang mais c'est bien sûr!". Du coup, les chats n'ont jamais une explication complète, et c'est pour ça que les chats ne savent pas programmer. Du coup, on peut souvent les retirer de la ligne de commande, comme dans l'exemple ci-dessus.
Alors là, franchement, chapeau bas. C'est la meilleure explication contre le "cat xxx |" que j'aie jamais entendu. Nette, précise, bien fondée, scientifiquement acceptable... Bref, tout qui va bien!
Encore une fois, bravo !!!
/F - Qui va bientôt avoir un "cat" pourtant...
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Le 12665ième jour après Epoch,
Yves Rutschle écrivait:
On Fri, Sep 03, 2004 at 10:46:38PM +0200, Jeremy Monnet wrote:
PS : pourquoi après avoir des heures, on trouve souvent une soluce 3 minutes
après avoir posé la question ?
PS2 : peut-être parce qu'on a réfléchi correctement a sa formulation entre
temps ?
Correct, c'est pour ça qu'il est souvent utile d'expliquer
le problème à son chat: on lui explique, et au milieu de
l'explication on s'exclame "bon sang mais c'est bien sûr!".
Du coup, les chats n'ont jamais une explication complète, et
c'est pour ça que les chats ne savent pas programmer. Du
coup, on peut souvent les retirer de la ligne de commande,
comme dans l'exemple ci-dessus.
Alors là, franchement, chapeau bas. C'est la meilleure explication
contre le "cat xxx |" que j'aie jamais entendu. Nette, précise, bien
fondée, scientifiquement acceptable... Bref, tout qui va bien!
Encore une fois, bravo !!!
/F - Qui va bientôt avoir un "cat" pourtant...
--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Le 12665ième jour après Epoch, Yves Rutschle écrivait:
On Fri, Sep 03, 2004 at 10:46:38PM +0200, Jeremy Monnet wrote:
PS : pourquoi après avoir des heures, on trouve souvent une soluce 3 minutes après avoir posé la question ? PS2 : peut-être parce qu'on a réfléchi correctement a sa formulation entre temps ?
Correct, c'est pour ça qu'il est souvent utile d'expliquer le problème à son chat: on lui explique, et au milieu de l'explication on s'exclame "bon sang mais c'est bien sûr!". Du coup, les chats n'ont jamais une explication complète, et c'est pour ça que les chats ne savent pas programmer. Du coup, on peut souvent les retirer de la ligne de commande, comme dans l'exemple ci-dessus.
Alors là, franchement, chapeau bas. C'est la meilleure explication contre le "cat xxx |" que j'aie jamais entendu. Nette, précise, bien fondée, scientifiquement acceptable... Bref, tout qui va bien!
Encore une fois, bravo !!!
/F - Qui va bientôt avoir un "cat" pourtant...
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
