Re: Allez perle ! ('etait Re: [SSFR] Comptage)

[Philippe Jacquot <philippe.j@xxxxxxxxx>]

Christophe Martin a écrit :

> En premier lieu, on est a peu pret d'accord pour dire
> quand c'est simple nawk et pis voila ! et quand c'est
> complique c'est perl, mais....
>
>  
Toutafé

> Philippe Jacquot a écrit :
>  
>
> > Christophe Martin a écrit :
> >    
> [cric crac croc]
>  
>
> > > La plupart du temps, si c'est juste pour tier trois colonnes et
> > > additionner 4 nombres, c'est pas la peine de sortir perl, nawk fait
> > > ca tres bien et en plus y'a des cas ou nawk est tres sup'erieur
> > > `a perl. Selon les dire du grand Larry soi meme, par la voix de
> > > perlvar(1) :
> > >
> > >      
> [jblouing]
>  
>
> > Entièrement d'accord. Toutefois lorsqu'il s'agit d'effectuer, à partir
> > du même fichier de plusieurs centaines de lignes, différents
> > traitements, tris et affichages, il est considérablement plus efficace
> > de tout charger une fois pour toute (genre dans un tableau
> > bidimensionnel) pour ensuite utiliser des fonctions de tri ou
> > d'affichage (vazy pour faire un tri complexe avec awk (qui reste orienté
> > lignes).. bonjour la réentrance :-)).
> >    
> Ben oui et non.
> Nawk fait des tableaux multidimensionnels tres bien. et pis si
> tu veux faire des tris, c'est pas sorcier de trouver un algo
> quicksort et de l'implanter en awk. Je le sais, je l'ai deja fait.
> (Juste, je retrouve plus ce script, ce qui peut pas arriver avec perl
> qui doit bien avoir ca en interne...;-)
>
>  
Certes, certes.

> Mais le probleme c'est qu'on a tendance a tout charger en memoire (pas le
> choix pour trier puisqu'avant d'avoir la derniere valeur, on peut pas
> deviner ou la ranger (Les pros du tri : pas taper, je sais qu'il esxiste
> des tris pour tout et toutes les conditions etc... etc...))
> Et quand on charge tout en memoire un jour ou l'autre ca plante.
>
>  
Encore une fois, d'accord avec toi; ça m'a bien heurté au moment 
d'écrire cette phrase, mais c'était pour évoquer un cas "extrème", où le 
traitement ne peut définitivement pas s'opérer de manière séquentielle, 
ce qui ne semble pas être le cas de "débutant debian". Le truc du 
tableau, c'était surtout pour mettre en évidence l'algoritmie des 
traitements suivant, s'il avait voulu générer plusieurs rapports à 
partir du même fichier de log (plutôt que de lancer plusieurs script 
dédiés). Et c'était surtout pour inviter "débutant debian" à envisager 
le problème dans sa globalité plutôt que d'improviser au coup par coup. 
Bref, c'était didactique et non pratique.  :-)

Sinon, bien sur, je préfère infiniment faire mes one-line en bash; c'est 
bien plus amusant/gratifiant.  :-)
En général je passe à perl quand aucune commande bash (que je connaisse) 
ne fait l'affaire, ou pour la portabilité ou les interfaces (ldap, sql, 
snmp, ..)

> sed peut traiter des fichiers de plusieurs Peta-octets (en fait il a pas de
> limite) pourvu que les lignes tiennent dans le pattern-space
> Avec awk, j'ai tendance a construire des trucs genre traitement en ligne,
> et eventuellement un petit tableau recapitulatif, ca bouffe rien en RAM. Par
> contre, les horreurs comme cdlabelgen (un bidule en perl) qui font :
> 	slurp $document
> 	slurp $template
> 	$template =~ s/MARQUE-OU-INSERER-LE-DOCUMENT/$document/
> 	print template
> Ca merde le jour ou un con comme moi, veut y inserer un document pas si
> enorme, mais quand meme pas si petit (121 Mo).
> alors qu'en separant le template en deux, un bon vieux
> 	cat template-1 document template-2
> insererai un document de plusieurs GIGA sans broncher.
>
> Bref, J'aime pas "Tout charger en memoire", ca fait souffrir les machines.
> Quand y'a pas le choix, ou quand 3 lignes de perl font 678354165 lignes
> de bash/sed,nawk,find,grep,join,cat,<,>,rm,|,xargs,eval etc...
> alors bien sur...
>
>  
On est bien d'accord (c'est beau non ? ;-))

> > Enfin, ce n'est qu'un avis de béotien.   :-)
> >    
> Tout pareil ;-)
>
> 	Bon week end
> 	Christophe
>
> PS
>  
Bon week-end itou

pj

--
Sparx Inc.
34 rue du Sentier
75002 Paris
Tel. +33 (0) 1 44 34 29 21
Std +33 (0) 1 44 34 29 29
Fax +33 (0) 1 55 73 17 07
http://www.sparx.com

begin:vcard
fn:Philippe Jacquot
n:Jacquot;Philippe
org:Sparx
adr:;;34 rue du Sentier;Paris;;75002;France
email;internet:philippe.j@xxxxxxxxx
title:System administrator
tel;work:+33 (0) 1 44 34 29 21
tel;fax:+33 (0) 1 55 73 17 07
x-mozilla-html:FALSE
url:http://www.sparx.com
version:2.1
end:vcard