Petite question au pingouins (qui ne font pas de RP sekk's)

Bon cela s'adresse en particulier a ceux qui ont une connaissance en informatique assez poussée. Il s'agit d'un probleme lié a Linux, du Bash et du perl.

Bon je sais c'est pas tout beau et ca sonne un peu vilain, ben c'est meme aussi vilain que celui qui parle en BA, CA, RM et autre sur un serveur RP (bon dsl je m'égare )

Donc voila j'ai un programme principal et un sous programme que voici bon c'est peut etre pas optimisé (je suis pas un nymphormaticien mais plutot un nelectronicien a la base XD ):

txt2bin.sh

Code:

#! /bin/sh

echo Nombre de pas du brasseur?
select nbpas in 15 30 60 120
do
angle=0
mkdir binary
for toto in $(ls -C1 champ*.gz)
do
   rm champ.txt
   gzip -d -c $toto | tail -n +2 >> champ.txt
   perl txt2bin.pl
   mv champ.bin ./binary/$angle.bin
   echo $((angle=$angle+360/$nbpas))

done
done
exit 0

fichier : txt2bin.pl

Code:

#!/usr/bin/perl

open ( FID, "champ.txt" );
open ( FOD, ">champ.bin" );
while ($ligne = <FID>) {
   @listev = split (' ', $ligne);
   foreach $value ( @listev ) {
         print FOD pack("d",$value);
         }
}
close (FOD);
close (FID);

Que font ces programmes ?
Tout simple en principe ils sont sensés transformé un ensemble de fichier contenant des doubles codé en ascii en des format doubles codé en binaires, et ce pour un gain de place.

Le programme en lui meme semble bien fonctionné, toutefois j'ai un probleme de perte de donnée (environ 2470). Apres un debug BDSM (violent et severe) du code j'en ai conclut que le probeme se situait là :

Code:

   gzip -d -c $toto | tail -n +2 >> champ.txt

Aurais je mal comprit le Gzip ? car lorsque je passe en mode graphique de linux et avec un clic droit et décompressé ces octets ne disparaissent pas.


S'il y avait un informaticien dans la salle qui pouvait venir a mon aide ?

Ton truc ressemble vraiment à du charabia pour moi xD

A première vue aucune chance que ca provienne de ca ? :

Code:

for toto in $(ls -C1 champ*.gz)

Raisonnement ptet tordu mais ton truc ressemble à une boucle et semble marcher à moitié (si j'ai bien compris le problème c'est une perte de données donc il marche partiellement ^^) donc ca peut foirer au niveau de la boucle.

Après j'ai aucune idée de comment marche ce langage là :/

décidement je ne comprendrais jamais rien au langage sms

Je ne comprend pas à quel niveau tu situes ta perte de données. Est ce au niveau de l'ensemble des fichiers ? Si oui, il faudrait en effet se pencher sur la ligne de code:

Citation :

for toto in $(ls -C1 champ*.gz)

Ou bien est ce au niveau du fichier "champ*.gz" lui même, ce qu'il contient ?
D'après ce que j'ai compris, ça serait plutôt le second cas.

La commande :

Citation :

gzip -d -c fumble.gz

décompresse (-d) le fichier fumble.gz compressés en .gz vers la sortie standard (-c) du shell.

La commande :

Citation :

tail -n 2 flamby

renvoie les deux dernières lignes (-n 2) que contient le fichier flamby (généralement un fichier ascii).

La commande :

Citation :

(ma-commande) >> champ.txt

est une redirection et permet d'écrire à la fin du fichier "champ.txt" sans l'écraser, tout ce qui doit normalement apparaître sur la sortie standard du shell si la commande (ma-commande) était exécutée seule.

Donc, en gros, la commande :

Code:

gzip -d -c $toto | tail -n +2 >> champ.txt

décompresse le fichier $toto (donc le fichier du type "champ*.gz" issu de ta boucle "for") et renvoie tout ce qui a été décompressé vers la commande "tail". Par contre, comme on l'a indiqué, la commande "tail" telle qu'elle est paramètrée ne va renvoyer que les deux dernières lignes de tout ce qui a été décompressé. Par conséquent, s'il manque des données, ça peut venir d'ici selon moi. Le résultat issu de la commande "tail" est alors écrit à la fin du fichier "champ.txt".

Voilà, si ça peut t'éclairer un peu ... j'espère que j'ai été assez clair

Oh ben pourquoi il n'y a plus personne ?

______________________________

Une tite remarque :
à mon avis, tu peux supprimer la ligne de code:

Citation :

rm champ.txt

et remplacer :

Citation :

gzip -d -c $toto | tail -n +2 >> champ.txt

par:

Citation :

gzip -d -c $toto | tail -n +2 > champ.txt

En principe, ça doit réaliser la même chose.

vous etes fou....

*comprend rien a leur dialogue*

Le moyen-age c'est telement plus simple

*prend sa rapiere et va shooté un gob*

donc dans les fichiers .gz (exemple réel : champ-01-01.gz. il y en 60 se sont des fichier textes formaté comme suit (ces données sont généré par un calculateur scientifique de résolution d'équation aux dérivées partielles pour anecdocte):

0.1211 0.25777 0.222555
0.5555 -0.111225 0.75589

et ce sur 16641 lignes et de 150 colonnes. Chaque nombre est espacé d'un espace et chaque fin de ligne par un caractere \n.
Donc l'idée du truc est l'automatiser sur linux par le biais de boucle et d'un d'un petit script en perl convertissant le tout en binaire. Avant 2Go et en binaire : 900 Mo donc un gros gain de compression

La perte de donné semblerait se passer au niveau de la ligne coté, a la décompression je perds exactement 150 valeurs a chaque fois dans le fichier extrait en binaire. Donc soit c'est l'extraction qui me les fait disparaitre, soit la conversion Ascii -> binaire.

PTZ 3 24 FJTLV 32 *essaye de communiquer avec ces être étranges*

Citation :

toto

J'ai d'ailleurs une blague sur Toto....

C'est toto qui va au mar...

Quoi s'pas ca? bon oki je sors

tu perds 150 valeurs et tu as 150 colonnes, en gros il te bouffe une ligne complete ?

ce qui me semble le plus probable en effet, je vias tenter de voir si ca vient d'une ligne complete. Enfin je pourrais pas avant demain.

Bon probleme resolu.

Cause un copier coller manqué, que j'ai oublié de corriger.

Cela venait du

Code:

gzip -d -c $toto | tail -n +2 >> champ.txt

J'usais du

Code:

tail -n +2

pour dégager la premiere ligne de la génération de la base pour la compresser, celle ci donnait des info de formatage de date et de logiciel qui m'était guere utile.

Donc la solution est en fait

Code:

gzip -d -c $toto >> champ.txt

Merci de votre aide, dsl de vous avoir perturbé avec cette question plus que pointue

Ben chais pas vous, mais moi, je suis soulagé pour le coup...

*contente d'avoir ete ... inutile *

De rien de rien , a quoi sert la connaisance si ce n'est a etre partarger *sifflotte*