Newsgroup: it.comp.lang.perl
Titolo: "Spezzare" un file

Salve a tutti!
Io avrei bisogno di effettuare delle ricerche di stringhe in u file di
testo (unix) di circa 170Mb.
Esistono comandi per fare in modo di esaminare solo poche centinai di kb
per volta? Come capirete caricarsi tutto in memoria è quasi una follia
.. ho provato a cercare un po' in internet un comando del genere (sono
autodidatta eheh) ma senza successo..
Grazie
Fabrizio



mhh, se non mi sbaglio nelle faq ufficiali del perl ci sono alcune
soluzioni per lavorare con i file, tipo leggere solo una riga..
Potresti leggere 100, 1000 righe alla volta e tenere la traccia...
--
http://www.pigmalion.info/
Internet è uno dei veicoli più validi per la difesa della libertà,
poiché offre la verità a chi vuole vederla e intenderla...
Vinton G. Cerf

 autodidatta eheh) ma senza successo..
Guarda io ho avuto un problema analogo anche se le dimensioni erano
decisa,mente piu' piccole.
Ad ogni modo, al tempo, mi consigliarono il  modulo Tie::File.
Spettacolare.
Praticamente vedi il file come un array e lo maneggi come tale...
Inoltre vede riga per riga (e non carica nulla in memoria!!) e quindi
molot comodo per maneggiamenti sequenziali...
Ti rimando a CPAN: 
http://search.cpan.org/~jhi/perl-5.8.1/lib/Tie/File.pm
Ti invio anche un estratto:
Tie::File represents a regular text file as a Perl array. 
Each element in the array corresponds to a record in the file. 
The first line of the file is element 0 of the array; 
the second line is element 1, and so on.
The file is not loaded into memory, so this will work even for gigantic files.
Changes to the array are reflected in the file immediately.
Lazy people and beginners may now stop reading the manual.
-- 
nathanvi
ICQ --> 20318568
mail --> newsgroup @ 
nathanvi.it

 soluzioni per lavorare con i file, tipo leggere solo una riga..
Ecco qui le FAQ (tradotte in italiano) che contengono la chiave di ricerca
"file":
http://www.perl.it/documenti/faq/faqsearch.pl?q=file
Qualcosa di utile alla circostanza pare esserci. ;)
Michele.

, scriveva:

Veramente non capisco bene il problema: se il file è organizzato in righe,
la consuetudine è quella di leggere una riga alla volta:
    open IN, '< file_di_testo';
    while (<IN>) {
    ....
    }
la bufferizzazione automatica dell'input è di solito sufficiente a
garantire comunque una buona efficienza. Altrimenti si possono usare altre
strategie.
Se il file non è organizzato in righe, si può vedere se si riesce ad
impostare un terminatore di record che legga un'"unità logica" alla volta,
con qualche confidenza che non sia troppo grande.
In ogni caso e sempre è possibile usare read per leggere quanti byte si
vogliono.
Ciao.

    }
In effetti avrei dovuto dire che perl permette di leggere si una riga
alla volta ma il particolare era che si può partire anche da qualsiasi
riga del file.
Ho per esempio fatto un piccolo script che legge delle citazioni
pescate a caso da un file di testo.
La funzione random non fa altro che scegliere un numero ed andare a
leggere la riga corrispondente nel file, senza doverlo scorrere ogni
volta.
Come avevo risposto io sembrava che anche solo leggere un file era una
cosa da FAQ :)


 volta.
Se funziona come credo, hai il limite di non poter sapere a priori
di quante righe e` composto il file. Nelle FAQ viene menzionato un
trucco ingegnoso per ovviare al problema:
 
http://www.perl.it/documenti/faq/faqview.pl?pag=5&faq=35
ciao,
S.
-- 
http://larsen.perlmonk.org

   
http://www.perl.it/documenti/faq/faqview.pl?pag=5&faq=35
uso proprio questa tecnica :)
E' proprio da qui che presi spunto.
Non ricordavo male quando mi riferivo alle faq :)


 Non ricordavo male quando mi riferivo alle faq :)
Ok, come non detto :)


Ok, come non detto :)
per carità hai fatto benissimo... io sono stato più 'lazy'... :)
volevo solo confermare che era proprio quello a cui mi riferivo nella
prima risposta..


 la consuetudine č quella di leggere una riga alla volta:
Si vero, quello che avevo in mente era spezzare il file per rendere piů veloce
la ricerca.
E' testo che riporta (divise per righe) parecchie informazioni sui geni del
dna (umano e non) codificate fino ad adesso. Siccome gli identificativi che
hanno sono in ordine numerico, potrei a seconda di quello che cerco partire da
punti piů avanzati invece che scorrermi tutto dalla prima riga, magari non
l'azzecco ma ci posso solo guadagnare in termini di tempo.
Se a questo aggiungete che non sono mai riuscito ad aprire quel file per
vederlo perchč mi piantava tutto... (ho un k6 350 con 256 di ram) ero un po'
preoccupato... anche perchč riavviare una macchina linux non č piacevole.
Cmq provo a vedere con le faq che mi avete consigliato.
Grazie!

preoccupato... anche perchè riavviare una macchina linux non è piacevole.
Che cosa usi per aprire il file? E vuoi vederlo o anche modificarlo? Alcuni
editor cercano di caricare tutto in memoria, il che è abbastanza complicato
nel tuo caso. Ci sono però visualizzatori o editor studiati proprio per
lavorare su file giganteschi con una certa efficienza (almeno in sola
lettura).
Ciao.

 certa efficienza (almeno in sola lettura).
Come il viewer interno di Midnight Commander?  :-)
Non parliamo invece dell'editor, che è un po' più lento.
-- 
Valerio Granato
http://www.musicoff.com
 - Music Online For Free
La Grande Comunità Online per Musicisti

Non parliamo invece dell'editor, che è un po' più lento.
Mi pare ragionevole.
Ciao.

 l'azzecco ma ci posso solo guadagnare in termini di tempo.
   Una soluzione può essere quella di associare ad ogni identificativo 
una posizione nel file, o mediante una funzione di calcolo (se i record, 
cioé le righe, sono a lunghezza costante) o con un indice esterno (che, 
però, andrebbe costruito all'inzio e poi ricostruito ogni volta che 
modifichi il file indicizzato).
   Nel primo caso, dato l'identificativo, la funzione ti 
restituisce--magari semplicemente moltiplicandolo per la dimensione data 
del record--l'offset del record relativo all'interno del file. Nel 
secondo caso, sempre dato l'identificativo, l'offset è scritto nel file 
di indice, sicuramente più maneggevole per quanto riguarda le dimensioni.
-- 
Alla prossima,
Marco