Newsgroup: it.comp.lang.perl
Titolo: uscire da un while

Ciao a tutti,
volevo sapere se esiste un comando che permetta di uscire da
un ciclo while in un qualsiasi momento.
Qualcosa tipo il break...
Ciao...
    Ivan

 wrote in message
news:3d8b0105$0$230$4d4e...@read.news.it.uu.net...

last
leggi: perldoc -f last
Una piccola osservazione per tutti quelli che fanno domande come questa:
LA RISPOSTA STA GIÀ SUL VOSTRO HARD DISK!
Basta leggere la documentazione di perl, possibilmente PRIMA di postare un
messaggio nel newsgroup.
;-)
Domizio Demichelis

 wrote in message
news:amf22q$475a6$1...@ID-159100.news.dfncis.de...


 Qualcosa tipo il break...
last,
ma io non te lo consiglio, e' una classica istruzione ridondante che
sembra che ti faciliti le cose ma, in algoritmi complessi, ti puo'
mettere nei guai. Per lo stesso motivo che nella teoria si dice "goto
considered harmful".
Nel piu' semplice dei casi basta una variabile "flag" in piu' o una
condizione del while scritta meglio.
Ad ogni modo, se e' uno script piccolino usa pure "last".
 Raffaello

 mettere nei guai.
La bellezza del perl sta proprio nel rendere l'uscita da un ciclo while
il più chiara possibile, senza sovraccaricare necessariamente le
istruzioni.
Cosa c'è di complicato, o fuorviante, in un
	while (condition) {
		last if (another_condition);
 
		[...]
	}
?
E` decisamente poco ambiguo, e permette di focalizzare l'attenzione sul
motivo del while (ciclare fino a che non si verifica una condizione).
Ciao,
 Emmanuele.
-- 
Emmanuele Bassi (Zefram)           [ 
http://www.radiance.d2g.com/~zefram
 ]
GnuPG Key fingerprint = 4DD0 C90D 4070 F071 5738  08BD 8ECC DB8F A432 0FF4

 wrote in message
news:Pine.OSF.4.31.020920...@harry.molgen.mpg.de...

COOOOME??? Stiamo facendo UN POCHINO di confusione eh???
Magari il tuo commento potrebbe essere appropriato per la funzione "goto"
appunto, ma qui stiamo parlando di un TOTALMENTE chiaro e lineare "last",
che è una linearissima e semplicissima forma di uscita da un blocco
ripetuto, quindi il tuo post sta solo confondendo le idee a chi ti legge.
Ricordarti che il "goto" non c'entra niente con "last"!!!! Se vuoi
rispolverarti un po' le idee:
perldoc -f last
perldoc -f goto
Per Ivan: il commento di Raffaello si riferisce probabilmente alla funzione
goto, che anch'io non ho MAI sentito la necessità di usare. Il last invece è
una normalissima forma di controllo di ciclo, che anzi ti consiglio di usare
fra le primissime linee del blocco stesso. Verifica SUBITO la condizione che
ti farebbe uscire dal blocco, così il programma non perde tempo a fare cose
che poi magari non sono servite a nulla se la condizione lo fa uscire.
Esempio:
while (<DATA>)
{
    chomp;
    last if /^__END__/;    # esce subito quando arriva alla linea che inizia
con '__END__'
    next if /^\#/;  # salta immediatamente la linea che contiene un commento
    # fai qualcosa con le altre linee
    #...code
    # ...code
    #...code
    # ...code
    #...code
    # ...code
}
ciao
Domizio Demichelis

Domizio Demichelis wrote:

Io non la vedo in modo così categorico (e urlante), come vedi la richiesta è
stata
gentile, non è detto che non abbia letto la doc e non l'abbia comunque
trovato,
eppoi il thread genera sempre approfondimenti, tra l'altro spesso tuoi, che
sono
utili a tutti.
Siano benvenute le richieste, purché garbate, anche se possono sembrare
banali come questa! :-)
    - Enrico

banali come questa! :-)
Sono d' accordo.
Ciao
Daniele che risponde a inmodis at tiscalinet dot it (e comunque
non serve a niente, continuano a impestarmi lo stesso :-(( )

 Daniele che risponde a inmodis at tiscalinet dot it
A prima vista sembrava una frase in latino.. :-))

 wrote in message
news:3D8C318A...@sorcinelli.it...

hmmmm.... nemmeno io la vedo in modo così categorico, però URLANTE sì :-).
Probabilmente non ho spiegato abbastanza bene i miei pensieri al riguardo, e
adesso, rileggendolo, mi rendo conto che un messaggio scritto così potrebbe
far pensare - appunto - quello che avete pensato tu e Daniele. Non mi sembra
comunque di aver spaventato Ivan (che è la cosa più importante) che mi ha
pure ringraziato. Chiedo venia per non essermi spiegato bene, e siccome il
commento di Daniele è più articolato del tuo (non è una critica per nessuno,
OK :-) ) per comodità risponderò dettagliatamente a tutta la questione nel
post di risposta al suo messaggio.
ciao
Domizio

 semplice o scontato; ...
Se posso essere sincero (ma rimanga fra noi :-)), io direi che com'è
organizzata la documentazione di perl al momento FA PROPRIO SCHIFO! :-( e
questo non solo per un neofita, ma anche per un cosidetto "esperto"!
Comunque non voglio iniziare qui una nuova polemica... voglio solo dire che
condivido in pieno l'opinione di Daniele al riguardo.
Ciò premesso, credo che comunque un neofita dovrebbe sforzarsi un po'
(magari anche molto) e andarsi a leggere la documentazione, per questo nella
prima linea del post ho scritto il comando richiesto, e - come faccio
sempre - ho scritto nella linea successiva anche dove impararsi il comando
(perldoc -f last).
La mia osservazione urlata, mal spiegata forse e sicuramente fraintesa, non
voleva essere una critica alla "banalita" della richiesta, che anzi
personalmente non mi è sembrata poi nemmeno così banale, visto come è stata
articolata la domanda, ma voleva essere solo quello che ho scritto: "Una
piccola osservazione per tutti quelli che fanno domande come questa".
SE UN UOMO HA FAME, NON DARGLI UN PESCE, MA INSEGNAGLI A PESCARE!
Urlare a tutti "LA RISPOSTA STA GIÀ SUL VOSTRO HARD DISK!" a me sembra un
modo, forse un po' rude :-), ma sicuramente efficace, di punzecchiare tutti
quanti perché si sforzino un po' a cercare nella (terribilmente mal
organizzata :-)) documentazione. Se insegnamo alla gente a pescare facciamo
loro un favore, se diamo loro un pesce, risolviamo il loro problema
momentaneo e li stimoliamo a dipendere da noi.
Enrico dice che "non è detto che non abbia letto la doc e non l'abbia
comunque trovato".... VERO, VERISSIMO, ma allora la mia osservazione urlata
provocherà che nella prossima domanda lo stile sarà un po' più simile a
questo:
"ho letto la tal cosa < citazione > nella documentazione relativa alla tal
funzione, e non ho capito come si possa fare a..."
Questo stile, credo che non solo dia prova di buona volontà, ma soprattutto
stimoli chi risponde ad "adottare" il neofita come se fosse suo "figlio in
programmazione" :-).
Personalmente mi piace moltissimo aiutare e rispondere a chiunque ne abbia
bisogno, a patto che:
1. O sia una richiesta del tipo: "Dove potrei trovare la tale
informazione?"...
2. O se è una richiesta tecnica, mi dimostri che ha fatto tutto quanto in
suo potere per provarci da solo, e SICCOME non ci è riuscito ALLORA chiede
aiuto.
Quello che vorrei evitare su questo newsgroup è stimolare la pigrizia
mentale che nasce proprio dal rispondere troppo facilmente "questo si fa
così", spesso senza dare informazioni su DOVE potersi documentare meglio su
quel tal argomento!
A tal proposito colgo l'occasione per lanciare un'idea: perché non postiamo
tutti quanti una specie di guida di quello che riteniamo utile sappia chi
chiede e chi risponde, e poi, raccogliamo e riassumiamo i principi salienti
in una specie di guideline e la postiamo nel newsgroup periodicamente, in
modo da dare una traccia a tutti e risolvere a monte i problemi
risolvibili?!
Fatemi sapere
ciao
Domizio Demichelis


OK!
Ciao
    - Enrico

 post di risposta al suo messaggio.
OK
Bye,
    - Enrico

 risolvibili?!
Non ho capito.
- Se intendi un manifesto che suggerisca le modalità di post qui,
esiste già o al limite se ne mutua qualcuno esistente (quello del mod_perl è
ottimo,
http://perl.apache.org/maillist/email-etiquette.html
 e leggerlo non fa male).
Tieni
conto che questa lista non è moderata, e può essere solo una guida per
ottenere migliori risultati dai propri interventi.
- Oppure intendi un DIGEST settimanale di ciò che si è detto, annunciato,
chiesto e risolto nelle news? In tal caso se hai tempo e voglia: +1
    - Enrico

 chiesto e risolto nelle news? In tal caso se hai tempo e voglia: +1
Nonono.... definitivamente non riesco più a spiegarmi bene in italiano.
Chiedo scusa (anche per le frasi sgrammaticate che mi accorgo di aver
scritto spesso), è che ho il cervellino limitato, e quando ci entra una
nuova lingua se ne va una vecchia.... oltretutto non sto in Italia da
parecchi annetti :-)
Volevo solo dire di fare un messaggio semplicino semplicino, scritto in
italiano che contenga i consigli per chi scrive una domanda... come per
esempio una lista di cose da fare prima di un post:
#1. Cercare nella documentazione di perl usando il comando perldoc. (Per
sapere come usare perldoc scrivere dalla command line 'perldoc perldoc')....
#2. ....
#n. Fare una ricerca qui: 
http://www.google.com/advanced_group_search?hl=en
inserendo il nome del gruppo it.comp.lang.perl e le parole chiave che si
cercano (probabilmente l'argomento è già stato trattato e spiegato, quindi
avrete una risposta immediata alle vostre richieste)
....
#n. Nel post di richiesta, per favore CITARE dove avete già cercato una
risposta, e spiegare dettagliatamente COSA non è chiaro
#n. In caso di code che "NON FUNZIONA" provare a farlo girare con "use
strict; use warnings" che danno ottime indicazioni su cosa potrebbe "NON
FUNZIONARE" ...
ecc. ecc...
e una lista di principi da seguire quando si risponde a una richiesta, come
per esempio... ricordarsi di citare una fonte di approfondimento se
possibile, indicare la guideline a chi pare averla ignorata nel suo
messaggio, e così via. Credo che in questo modo tutto funzionerebbe meglio,
e fornirebbe utili informazioni a tutti su come utilizzare al meglio il
newsgroup.
Il fatto della pubblicazione periodica, è legato al fatto che i messaggi
dopo un po' se ne vanno, così sarebbe utile ripostare la guideline in modo
che permanga nel newsgroup sempre.
Io non sono molto esperto di newsgroup, e magari ho detto delle ingenuità,
però se non mi sono perso qualcosa, direi che questo sarebbe un'iniziativa
di cui parecchia gente si potrebbe giovare.
ciao
Domizio


Come si sarà capito :-) vedo e rilancio.
Ciao
Daniele 


 Domizio Demichelis
Intendo dire che, se il tuo script in Perl e' parecchio incasinato (8
while annidati, puo' capitare) le condizioni del "last if" rendono il
codice piu' difficile da leggere.
while ( (cond_1) && (cond_2) && ... && (cond_n) )
	{
	...
	}
e' oggettivamente piu' leggibile di
while (cond_1)
	{
	...
	last if (cond_2)
	...
	last if (cond_n)
	}
Puoi comporre l'analogo controesempio con gli 8 while annidati.
... poi fai un grep "last". ;)
ciao
 Raffaello

 
...ed averne anche una copia in rete da qualche parte.
Tra l'altro Il "sito ufficiale" del gruppo, '
www.perl-it.org
' 
(213.26.99.70) è down da un po' di tempo, magari qui sicuramente
qualcosa c'era...
	- Enrico

}
a me sembra proprio che stai di nuovo facendo confusione: questa volta tra
il significato di "OGGETTIVAMENTE" e "SOGGETTIVAMENTE" :-)
Non vorrai davvero farci credere che quattro o cinque condizioni sulla
stessa riga siano OGGETTIVAMENTE più leggibili delle stesse condizioni prese
una alla volta? E quando debugghi, per sapere qual'è che ti ha fatto uscire
dal loop cosa fai? Conti?
Inoltre considera che anche solo con 4 condizioni (e non 8)
while (<DATA>)
{
    chomp;
    last if /^__END__/;
    last if cond_1;
    last if cond_2;
    last if cond_3;
    ....
}
scritto come suggerisci sarebbe
while (<DATA> && (not /^__END__/) && (not cond_1) && (not cond_2) && (not
cond_3)  )
{
    chomp;
    ....
}
e mi sembra che l'unica cosa chiara a tutti che ... è un bel casino :-))))!
Inoltre ti costringe a pensare in termini negativi, che non mi sembra mai
così diretto come pensare in termini postivi.
E poi, contrariamente a quanto affermi, mi sembra proprio che PIÙ è casinato
il loop e PIÙ avrai convenienza a usare il last.
Una domanda di carattere personale: ma i tuoi programmi tu li scrivi
sparandoli tutti su una sola riga? :-))))
ciao
dd

 sparandoli tutti su una sola riga? :-))))
Indentare.
while (
	(cond_1) &&
	(cond_2) &&
	.......
	(cond_n)  )
  {
  ...
  }
illeggibile vero ?
mah!
 Raffaello

 qualcosa c'era...
già... magari si fa prima ancora a postare solo il link :-).
OK, allora scriviamo quello che ci pare logico, e poi gli troveremo un
posto, anche non ufficiale.
ciao
dd

mah!
AHA!!! E proprio qui ti aspettavo!!! Allora perché ti ostini a voler
scrivere le condizioni al negativo, splittando una linea su differenti
linee, quando il last è fatto apposta per evitarti sti casini? Ahhh... sarà
mica per lo stesso motivo per cui non hai mai usato il debug? :-)
ciao
dd

 
Allora veniamo ad un caso "oggettivo", una cosa del tipo:
while (<DATA>) {
        &operazione_da_fare_comunque_e_sempre($_);
        last unless &operazione_da_fara_per_verificare_l'uscita($_);
}
come lo tradurresti in un'unica condizione di while?
se fai 
while ( <DATA> &&
        &operazione_da_fara_per_verificare_l'uscita($_)
        ) {
                &operazione_da_fare_comunque_e_sempre($_);
}
Cosi' facendo operazione_da_fare_comunque_e_sempre non sara' fatta nel 
caso in cui &operazione_da_fara_per_verificare_l'uscita($_) torni falso.
Potresti farlo cosi'
while ( <DATA> &&
        &operazione_da_fara_per_verificare_l'uscita($precedente)
        ) {
                &operazione_da_fare_comunque_e_sempre($_);
                $precedente=$_;
}
ma sinceramente e' molto brutto, oppure
while ( &operazione_da_fara_per_verificare_l'uscita($_) &&
        <DATA>
        ) {
                &operazione_da_fare_comunque_e_sempre($_);
}
Ma rischi di valutare in operazione_da_fara_per_verificare_l'uscita un 
$_ "spurio che arrivi da qualche ciclo precedente, allora dovresti 
prima del while mettere $_="qualcosa", ma cosi' devi fare la sub 
operazione_da_fara_per_verificare_l'uscita in modo che discrimini 
"qualcosa" come valore da non elaborare, ed e' brutto lo stesso.
-- 
Saluti,
Giancarlo

 }
a questo non avevo nemmeno pensato... mi bastava già l'incasinamento
grafico/logico a cui costringe l'assenza del last :-).
Grazie per aiutarmi nella crociata a favore del last! :-)
dd
LAST OR NEVER!

 grafico/logico a cui costringe l'assenza del last :-).
Mi viene in mente un'altra cosa
while (<FILEHANDLE>) { .... }
setta $_ a quanto restituito da <>.
in 
while (<FILEHANDLE> && (condizione)) { .... }
l'assegnazione a $_ temo che non avvenga (ho fatto una provina veloce e 
sembrere proprio cosi), ne in "condizione" ne nel blocco del while, 
quindi devi anche pagare il prezzo di rinunciare alla variabile 
"magica".
-- 
Saluti,
Giancarlo

 Infatti non e' obbligatorio: i masochisti possono astenersi dall'usarlo :-).
Continuiamo a parlare in termini "io penso che Q e' meglio di P".
Quindi
1 - non ti scaldare
2 - accetta punti di vista altrui
 Raffaello

 wrote in message
news:Pine.OSF.4.31.020923...@harry.molgen.mpg.de...



ehi gente! C'è qualuno oltre al Raffaello che pensa che mi sono
"scaldato"???
A me piace fare delle battutacce (e le accompagno sempre con degli smiles
:-) ), quindi mi pare proprio evidente che non mi scaldo per niente, ci
mancherebbe!
Per quanto riguarda l'accettare i punti di vista altrui... ma ti ho mai
obbligato a usare il debuggher? Se non lo vuoi usare sai cosa me ne frega
:-)... io accetto anche chi si da le martellate sulle palle e poi dice che
gli piace... solo che ... per lo stesso principio di accettare i punti di
vista altrui... potrò almeno dire che fa male ai coglioni? :-)
ciao
dd

 
Qui ci posta giornalmente gente del tipo Jarkko Hietaniemi, brian_d_foy, Ask Bjoern Hansen,
quindi vedi tu: prima un'attenta lettura dell'archivio della lista è d'obbligo..., poi
si 'ascolta' eppoi se hai buone idee non vedo perché non postare  :-)
	- Enrico

 wrote in message
news:amn7g3$2o2k$1...@stargate1.inet.it...

Questo a me era venuto in mente, ma pi era parso di ricordare che
l'operatore && valuta l'espressione che segue esattamente come se fosse in
una seconda linea, quindi ad occhio e croce avrei detto che il $_ funzionava
allo stesso modo in entrambi i casi. Se noti (senza provarlo) ho pure
scritto while(<DATA> && (not /^__END__/)... presupponendo che la cosa
funzioni. Sei proprio proprio proprio sicuro che così si perde la
definizione di $_?
ciao
dd

 $_?
Sě, e non solo quello.
Ad esempio, questo codice:
 
  while( ( $_ = <STDIN> ) && 1 ) {  # ...
*non* č equivalente a:
  while( <STDIN> ) {  #...
Ma non voglio negarvi il piacere di scoprire in quali condizioni il
comportamento č differente.
Max

 definizione di $_?
ho provato questo:
while (<> && 1) {
        print "$_\n";
}
E, buttandogli dentro un file qualunque a STDIN, non stampa nulla se 
tolgo "&& 1" invece stampa.
-- 
Saluti,
Giancarlo

 tolgo "&& 1" invece stampa.
VERO!... infatti perché funzioni devi settare esplicitamente $_ ... o cosě
 while ( ($_ = <>) && 1 ) { print }
o senza parentesi usando 'and' che ha una precedenza inferiore... cosě
 while ( $_ = <> and 1) { print }
altrimenti " ( <> && 1) " usa <> nell'espressione e lascia $_ undef.
In conclusione allora... caro Raffaello, oltre a essere una schifezza
logico/estetica, il tuo sistema non funziona neppure :-))))
Ma cosa ti ha fatto 'sto last che ti fa incazzare cosě tanto eh? :-)
ciao
dd
USE LAST, PLEEEEEEEEASE! :-)

 wrote in message
news:Pine.LNX.4.21.020923...@localhost.localdomain...

Intendi la differenza tra le espressioni "$_ = <STDIN>" e "<STDIN>"???
Mah... mal spiegato: la prima ritorna un boolean mentre la seconda una
stringa...
Se invece intendi in concomitanza con && 1... e cioč
( $_ = <STDIN> ) && 1 e <STDIN> la differenza č la stessa.
Comunque non essere cosě gentile... negamelo, negamelo 'sto piacere, che non
mi viene in mente niente altro.
ciao
dd

 "magica".
<FOO> assegna a $_ sse e' l'unica cosa nella condizione
di un while. E' documentato in perlop (I/O operators).
Mattia

 wrote in message
news:Xns9292C60E01A0E...@192.168.9.1...

Spiacente di contraddire sempre, però questo NON è vero!
prova questo:
==== FILE ====
#! /usr/bin/perl
while ( 1 && <DATA>) {print}
__DATA__
uno
due
tre
==== END FILE ====
Il fatto è che l'operatore && ritorna sempre l'ultima espressione valutata,
da ciò consegue che la cosa importante qui è l'ordine e NON la quantità,
infatti se tu il <DATA> lo metti alla fine di una serie di condizioni (vere)
legate da && verrà comunque sempre definito $_ , nonostante tu creda che
<FOO> debba essere usato da solo ! :-)
Questo discorso non salva comunque il fatto che il sistema proposto da
Raffaello (con le condizioni di uscita nel while, invece che in un last in
una linea del blocco) NON può utilizzare $_, in quanto $_ viene definito
solo DOPO che tutte le altre condizioni sono soddisfatte, cosa impossibile,
appunto.
ciao
Domizio

 che non mi viene in mente niente altro.
Se hai una shell, Unix prova questi due:
 echo -n "0" | perl -e ' while( $_ = <STDIN> ) { print; } ' 
 echo -n "0" | perl -e ' while( ( $_ = <STDIN> ) && 1 ) { print; } '  
La prima stampa '0', la seconda non stampa niente. (Il "-n" č importante.
Se lo togli le cose cambiano.)
Il fatto č che 
     while( $_ = <STDIN> )  {
č equivalente a 
    while( defined( $_ = <STDIN> ) ) {
Ciň nondimeno,
   if( $_ = <STDIN> ) {
*non* č equivalente a
   if( defined( $_ = <STDIN> ) ) {
 
Se $_ contiene soltanto '0', la prima espressione viene valutata come
falsa, mentre la seconda come vera.
Con espressioni piů complesse 'while' si comporta come 'if'.
Max

 Con espressioni più complesse 'while' si comporta come 'if'.
Dio mio come sono ignorante! E quel che è peggio è che non ho nemmeno una
shell unix :-(.
Comunque per la cronaca... queste "sottili" differenze sono le cose che odio
di più, perché non è detto che siano uguali su tutti i sistemi. Ad esempio
io sto facendo a pugni con un sistema solaris che è installato dal mio host,
dove a volte capitano cosette strane, come errori di sintassi che il perl di
windows non vede!
ad esempio... in un mio modulo stava scritta questa linea
__PACKAGE__->method_name qw|par1 par2 par3|;
bene, perl windows non fa una piega e funziona che è un piacere, mentre il
solaris che c'è sull'host mi dà (giustamente o no?) un errore di sintassi.
Lui lo vuole vedere scritto così:
__PACKAGE__->method_name ( qw|par1 par2 par3| );
Queste sono le cose che mi fanno incazzzzzzare :-@
ciao
dd


Ah... me ne stavo dimenticando un'altra:
new
{
    my $c = shift;
    bless \@_, $c;
}
Su perl win va secondo quello che ti aspetteresti, mentre su sto c.... di
solaris no. Mi ritrovo un oggetto [] e i parametri passati vanno a farsi
friggere! Per farlo andare devo scrivergli:
new
{
    my $c = shift;
    my $s;
    @$s = @_;
    bless $s, $c;
}
grrrrr :-@
ciao

 USE LAST, PLEEEEEEEEASE! :-)
No, Thanks.
kisses
 Raffaello

 errori di sintassi che il perl di windows non vede!
Sicuro che siano differenze nel porting e non nelle versione del perl?
prova un po un 
perl --version 
su entrambe le piattaforme.
Per me la differenza sta li.
-- 
Saluti,
Giancarlo

 Per me la differenza sta li.
Probabilmente sta lì... in effetti però a me non cambia molto la vita, se la
differenza sta nelle versioni o negli OS, perché in ogni caso ste cose fanno
girare le palle.
con "perl --version"
--------------------
This is perl, v5.6.1 built for MSWin32-x86-multi-thread
(with 1 registered patch, see perl -V for more detail)
Binary build 633 provided by ActiveState Corp. 
http://www.ActiveState.com
Built 21:33:05 Jun 17 2002
--------------------
This is perl, version 5.005_02 built for sun4-solaris
--------------------
con "perl -e 'print $]'"
5.006001
5.00502
però comunque mi sembra che delle versioni così poco differenti non
dovrebbero generare delle differenze sintattiche così grandi. Inoltre il
modulo passa il test per solaris 2.8 sun4-solaris di CPAN

 Raffaello (con le condizioni di uscita nel while, invece che in un
Non stavo discutendo di quello... mi riferivo solo alla parte
"quando <FOO> assegna a $_".
Ciao
Mattia

 "quando <FOO> assegna a $_".
si, questo era evidente, infatti il mio commento non era per te, ma era un
commento generale per il sistema proprosto da Raffaello.
Grazie per la tua dritta così autorevole.
dd

Non usi last, però sei simpatico :-))))
ciao
dd
PS Spiegami la differenza tra (condizione) e (<DATA>), PLEEEEEASE



La condizione del while, in tutti i linguaggi decenti e' semplicemente
una espressione booleana (true/false).
Qualcuno poi ha inventato quella cosa sporca chiamata "side effect"
(effetto laterale), per cui tu puoi fare 2 cose allo stesso tempo.
C'e' anche in C/C++.
Senza andare a parlare dei concetti di memoria e ambiente, ti accorgerai
che
 while (<DATA>) { ... }
fa molto di piu' di un semplice
 while ($x<10) { ... }
Questa e' una delle cose che nel libro bibbia del Perl e' chiamata
"oddity". Comodo si', ma "sporco". Loro si salvano dicendotelo prima. ;)
Ho visto i vostri esempi che riguardavano la scrittura di informazioni
nelle variabili speciali del Perl tipo $_. Questo e' un caso lampante di
"Side effect".
while(<DATA>) { ... }
legge il contenuto di un filehandle, il controllo booleano implicito e'
EOF.
-1- legge dal filehandle DATA e mette il contenuto nel tuo $_
-2- controlla l'EOF
E sono ben d'accordo con te nel dire che e' una bestemmia
fare
while ( (<DATA>) && _logic_cond_) { ... }
Mai sognato di proporre una schifezza del genere!
Io parlavo dell'uso "canonico" del while, non dell'oddity (<DATA>),
risposi ad una domanda sul comando while in generale, se ricordi.
Nei miei script che fanno il parsing di un testo, non necessito mai
di interrompere l'input da file, per questo non uso "last" dentro
while (<DATA>) { ... }
Se dovessi interrompere l'input da file, il last sarebbe di certo l'unica
soluzione decente.
Nel while ($x<10) { ... } non ne sento semplicemente l'esigenza
 Raffaello
P.S.: pensa al side effect che hai nel pattern matching. $`, $' , $1 , ...

... vabbé... allora ti perdoniamo :-)
dd

 ... vabbé... allora ti perdoniamo :-)
Sono commosso. ;)
 Raffaello

 era un commento generale per il sistema proprosto da Raffaello.
Ok, lo sospettavo, era solo per sicurezza
Ciao
Mattia

 __DATA__/__END__), DATA non funziona. (documentato in perldata)
Bene!! Detto questo, ho appena deciso che mi devo proprio documentare un po'
meglio sul compilatore di perl, e che scriverò un libro di esempi: non so ancora
quale titolo potrà essere più indicato "Esempi che non c'entrano un c...o"...
oppure "Esempi da non imitare"... oppure un più professionale "Esempi
inconsueti".
:-D
ciao
dd

 quale titolo potrà essere più indicato "Esempi che non c'entrano un c...o"...
ROTFL!
Sarebbe utilissimo! ;)
 Raffaello