Sur http://fr.wikipedia.org/wiki/UUOC#Cat_et_UUOC on voit l'exemple
typique d'« useless use of cat », à savoir « cat file | commande ».
Bien évidemment, « cat | commande » ou « commande | cat » serait
encore plus inutile. Mais qualifieriez-vous l'exemple suivant d'UUOC ?
On suppose que commande1 génère un code HTML tel que suit :
-------------------------------------------------------------------------
<html>
...
<body>
...
<p>
Vous pouvez faire du <a href='machin.html'>machin</a>.
</p>
<!-- MACHINTRUC
<p>
Vous pouvez faire du <a href='machintruc.html'>machin truc</a>.
</p>
MACHINTRUC -->
<!-- MACHINCHOSE
<p>
Vous pouvez faire du <a href='machinchose.html'>machin
chose</a>.
</p>
MACHINCHOSE -->
On suppose que commande2 fait quelque chose à partir de ce code HTML,
peu importe quoi. Enfin, on suppose que la commande revelemachin
retourne 0, 1 ou 2 selon que l'on doit laisser le code tel quel, ou
décommenter MACHINTRUC, ou encore décommenter MACHINCHOSE.
On a alors le script suivant :
-------------------------------------------------------------------------
case revelemachin in
1) FILTRE="grep -v MACHINTRUC" ;;
2) FILTRE="grep -v MACHINCHOSE" ;;
*) FILTRE=cat ;;
esac
Mais je trouve ta version plus propre et facile a lire, meme si ca veut dire utiliser une commande inutile.
Ah oui, je n'avais pas pensé à eval, que je n'utilise jamais. Avec eval je trouve trop facile de faire un code qui semble correct mais qui présente un trou de sécurité. Plus précisément, je trouve trop fatigant de devoir penser à chaque fois à tous les cas défavorables.
Quoi qu'il en soit, je vais donc laisser cette commande parfois inutile, pour la lisibilité.
Le 20/10/2008 15:42, Stephane CHAZELAS a écrit :
Alors, UUOC ou pas UUOC ?
Obviously not.
Merci de ta réponse.
Sauf que tu aurais pu l'ecrire:
case revelemachin in
1) FILTRE="|grep -v MACHINTRUC" ;;
2) FILTRE="|grep -v MACHINCHOSE" ;;
*) FILTRE= ;;
esac
Mais je trouve ta version plus propre et facile a lire, meme si
ca veut dire utiliser une commande inutile.
Ah oui, je n'avais pas pensé à eval, que je n'utilise jamais. Avec
eval je trouve trop facile de faire un code qui semble correct mais
qui présente un trou de sécurité. Plus précisément, je trouve trop
fatigant de devoir penser à chaque fois à tous les cas défavorables.
Quoi qu'il en soit, je vais donc laisser cette commande parfois
inutile, pour la lisibilité.
Mais je trouve ta version plus propre et facile a lire, meme si ca veut dire utiliser une commande inutile.
Ah oui, je n'avais pas pensé à eval, que je n'utilise jamais. Avec eval je trouve trop facile de faire un code qui semble correct mais qui présente un trou de sécurité. Plus précisément, je trouve trop fatigant de devoir penser à chaque fois à tous les cas défavorables.
Quoi qu'il en soit, je vais donc laisser cette commande parfois inutile, pour la lisibilité.
Che Averell
'lu Olivier,
Olivier Miakinen <om+ écrit : <snip>
Alors, UUOC ou pas UUOC ?
La bonne réponse est « on s'en fout ». En fait, soit on fait un UUOC dans un script pas particulièrement critique, et dans ce cas, la pénalité de forker un process qui ne sert à rien n'est pas pénalisante. Ou alors on est dans un cas où la pénalité de forker est pénalisante, et là, plutôt que de s'emmerder avec un script shell à réécrire, on pourrait plutôt se poser la question de réécrire le script en question dans un langage un poil plus évolué qui offre de meilleures perfs (et entre Perl, Ruby, Python, ou autres, il y en a pléthore).
Dit autrement, il est bon de connaître le principe du UUOC, de savoir que souvent il n'est pas nécessaire, qu'il vaut mieux faire autrement, mais c'est pas ça qui va mettre ta machine à genoux. À part ça, c'est juste un truc d'intégristes.
mes deux centimes.
'lu Olivier,
Olivier Miakinen <om+news@miakinen.net> écrit :
<snip>
Alors, UUOC ou pas UUOC ?
La bonne réponse est « on s'en fout ». En fait, soit on fait un UUOC
dans un script pas particulièrement critique, et dans ce cas, la
pénalité de forker un process qui ne sert à rien n'est pas
pénalisante. Ou alors on est dans un cas où la pénalité de forker est
pénalisante, et là, plutôt que de s'emmerder avec un script shell à
réécrire, on pourrait plutôt se poser la question de réécrire le
script en question dans un langage un poil plus évolué qui offre de
meilleures perfs (et entre Perl, Ruby, Python, ou autres, il y en a
pléthore).
Dit autrement, il est bon de connaître le principe du UUOC, de savoir
que souvent il n'est pas nécessaire, qu'il vaut mieux faire autrement,
mais c'est pas ça qui va mettre ta machine à genoux. À part ça, c'est
juste un truc d'intégristes.
La bonne réponse est « on s'en fout ». En fait, soit on fait un UUOC dans un script pas particulièrement critique, et dans ce cas, la pénalité de forker un process qui ne sert à rien n'est pas pénalisante. Ou alors on est dans un cas où la pénalité de forker est pénalisante, et là, plutôt que de s'emmerder avec un script shell à réécrire, on pourrait plutôt se poser la question de réécrire le script en question dans un langage un poil plus évolué qui offre de meilleures perfs (et entre Perl, Ruby, Python, ou autres, il y en a pléthore).
Dit autrement, il est bon de connaître le principe du UUOC, de savoir que souvent il n'est pas nécessaire, qu'il vaut mieux faire autrement, mais c'est pas ça qui va mettre ta machine à genoux. À part ça, c'est juste un truc d'intégristes.
mes deux centimes.
Chris
Che Averell a écrit : >...
La bonne réponse est « on s'en fout ». En fait, soit on fait un UUOC dans un script pas particulièrement critique, et dans ce cas, la
>...
juste un truc d'intégristes.
>... Je suis un peu d'accord avec le Che Averell Le mieux est bien souvent l'ennemi du bien, et je préfère un script lent et lisible plutôt qu'optimisé et incompréhensible
Enfin si je dois le maintenir ...
D'ailleurs c'est pour cette raison que je suis passé du
Epoque "age de pierre" ==> shell + awk + sed + grep
Epoque "Age de Bronze" ==> Shell + perl
Epoque "Industrielle" ==> shell + python
python est quand même très bien enfin IMHO
A+ chris
Che Averell a écrit :
>...
La bonne réponse est « on s'en fout ». En fait, soit on fait un UUOC
dans un script pas particulièrement critique, et dans ce cas, la
>...
juste un truc d'intégristes.
>...
Je suis un peu d'accord avec le Che Averell
Le mieux est bien souvent l'ennemi du bien, et je préfère un script
lent et lisible plutôt qu'optimisé et incompréhensible
Enfin si je dois le maintenir ...
D'ailleurs c'est pour cette raison que je suis passé du
Epoque "age de pierre"
==> shell + awk + sed + grep
La bonne réponse est « on s'en fout ». En fait, soit on fait un UUOC dans un script pas particulièrement critique, et dans ce cas, la
>...
juste un truc d'intégristes.
>... Je suis un peu d'accord avec le Che Averell Le mieux est bien souvent l'ennemi du bien, et je préfère un script lent et lisible plutôt qu'optimisé et incompréhensible
Enfin si je dois le maintenir ...
D'ailleurs c'est pour cette raison que je suis passé du
Epoque "age de pierre" ==> shell + awk + sed + grep
Epoque "Age de Bronze" ==> Shell + perl
Epoque "Industrielle" ==> shell + python
python est quand même très bien enfin IMHO
A+ chris
Olivier Miakinen
Le 20/10/2008 16:01, Che Averell a écrit :
Alors, UUOC ou pas UUOC ?
La bonne réponse est « on s'en fout ». [...]
[ coupe de plein de choses très justes ]
[...] À part ça, c'est juste un truc d'intégristes.
C'est pas faux...
Le 20/10/2008 16:01, Che Averell a écrit :
Alors, UUOC ou pas UUOC ?
La bonne réponse est « on s'en fout ». [...]
[ coupe de plein de choses très justes ]
[...] À part ça, c'est juste un truc d'intégristes.
[...] À part ça, c'est juste un truc d'intégristes.
C'est pas faux...
Tu sais pas ce que ça veut dire « intégriste » ?
(ref: http://www.youtube.com/watch?v=UlNQMLl-xjU)
Stephane CHAZELAS
2008-10-20, 17:16(+02), Chris:
Che Averell a écrit : >...
La bonne réponse est « on s'en fout ». En fait, soit on fait un UUOC dans un script pas particulièrement critique, et dans ce cas, la
>...
juste un truc d'intégristes.
>... Je suis un peu d'accord avec le Che Averell Le mieux est bien souvent l'ennemi du bien, et je préfère un script lent et lisible plutôt qu'optimisé et incompréhensible
Oui, sauf que "cat" est la commande pour concatener des fichiers, et que concatener un seul fichier peut paraitre moins lisible.
cat fichier | cat - | cat | paste | cut -b1- | grep '^' | sed b | awk 1 | comm -3 - /dev/null | dd 2> /dev/null | tee /dev/null | tail -n +1 | join | join -a1 - /dev/null | more | cmd
(pourquoi se limiter a cat)
est pour moi moins lisible que
cmd < fichier
ou
< fichier cmd
Enfin si je dois le maintenir ...
D'ailleurs c'est pour cette raison que je suis passé du
Epoque "age de pierre" ==> shell + awk + sed + grep
note que awk est un surensemble de sed et grep.
Epoque "Age de Bronze" ==> Shell + perl
Epoque "Industrielle" ==> shell + python
python est quand même très bien enfin IMHO
Question de gout, et je suis sur que python a deja ete supplanté par une demi douzaines de nouveaux languages encore plus hypes.
Cela dit, je suis plutot d'accord.
-- Stéphane
2008-10-20, 17:16(+02), Chris:
Che Averell a écrit :
>...
La bonne réponse est « on s'en fout ». En fait, soit on fait un UUOC
dans un script pas particulièrement critique, et dans ce cas, la
>...
juste un truc d'intégristes.
>...
Je suis un peu d'accord avec le Che Averell
Le mieux est bien souvent l'ennemi du bien, et je préfère un script
lent et lisible plutôt qu'optimisé et incompréhensible
Oui, sauf que "cat" est la commande pour concatener des
fichiers, et que concatener un seul fichier peut paraitre moins
lisible.
cat fichier | cat - | cat | paste | cut -b1- | grep '^' |
sed b | awk 1 | comm -3 - /dev/null | dd 2> /dev/null |
tee /dev/null | tail -n +1 | join | join -a1 - /dev/null |
more | cmd
(pourquoi se limiter a cat)
est pour moi moins lisible que
cmd < fichier
ou
< fichier cmd
Enfin si je dois le maintenir ...
D'ailleurs c'est pour cette raison que je suis passé du
Epoque "age de pierre"
==> shell + awk + sed + grep
note que awk est un surensemble de sed et grep.
Epoque "Age de Bronze"
==> Shell + perl
Epoque "Industrielle"
==> shell + python
python est quand même très bien enfin IMHO
Question de gout, et je suis sur que python a deja ete supplanté
par une demi douzaines de nouveaux languages encore plus hypes.
La bonne réponse est « on s'en fout ». En fait, soit on fait un UUOC dans un script pas particulièrement critique, et dans ce cas, la
>...
juste un truc d'intégristes.
>... Je suis un peu d'accord avec le Che Averell Le mieux est bien souvent l'ennemi du bien, et je préfère un script lent et lisible plutôt qu'optimisé et incompréhensible
Oui, sauf que "cat" est la commande pour concatener des fichiers, et que concatener un seul fichier peut paraitre moins lisible.
cat fichier | cat - | cat | paste | cut -b1- | grep '^' | sed b | awk 1 | comm -3 - /dev/null | dd 2> /dev/null | tee /dev/null | tail -n +1 | join | join -a1 - /dev/null | more | cmd
(pourquoi se limiter a cat)
est pour moi moins lisible que
cmd < fichier
ou
< fichier cmd
Enfin si je dois le maintenir ...
D'ailleurs c'est pour cette raison que je suis passé du
Epoque "age de pierre" ==> shell + awk + sed + grep
note que awk est un surensemble de sed et grep.
Epoque "Age de Bronze" ==> Shell + perl
Epoque "Industrielle" ==> shell + python
python est quand même très bien enfin IMHO
Question de gout, et je suis sur que python a deja ete supplanté par une demi douzaines de nouveaux languages encore plus hypes.
Cela dit, je suis plutot d'accord.
-- Stéphane
Olivier Miakinen
Le 20/10/2008 17:26, Che Averell a écrit :
[...] À part ça, c'est juste un truc d'intégristes.
C'est pas faux...
Tu sais pas ce que ça veut dire « intégriste » ? (ref: http://www.youtube.com/watch?v=UlNQMLl-xjU)
Excellent !
Le 20/10/2008 17:26, Che Averell a écrit :
[...] À part ça, c'est juste un truc d'intégristes.
C'est pas faux...
Tu sais pas ce que ça veut dire « intégriste » ?
(ref: http://www.youtube.com/watch?v=UlNQMLl-xjU)
