Newsgroup: it.lavoro.informatica
Titolo: Add linefeed and carriage return characters on the last line.

È una vita che trovo l'istruzione nel subject in vari how to Microsoft
(e per la verità, ricordo di aver letto istruzioni simili in altri
ambienti/piattaforme C o C++ in decenni passati).
Qualcuno ha idea se nel 2011 serve ancora veramente a qualcosa? :)
--
ale
http://ale.riolo.co.uk

 Qualcuno ha idea se nel 2011 serve ancora veramente a qualcosa? :)
Scusa, non ho afferrato il senso della domanda. Stai chiedendo se anno
2011 serve ancora mettere CR e LF al termine di una frase ? Mah, io
direi proprio di si',
cosi'comeanchemettereglispazitraleparoleperfacilitarelaletturaemagarimettereanchesegnidipunteggiaturacosi'darenderepiu'facilecapirequandounohafinitodiscrivereunafraseSenzasegnidipunteggiaturaCRLFecompagniabriscolaritengolafacilita'diletturadiunpostadesempiorisultidecisamentemiglioreTuchedici
:-)
C'ya
  STeve

 :-)
Sai che i Romani scrivevano proprio così :)
--
ale
http://ale.riolo.co.uk

 Sai che i Romani scrivevano proprio così :)
C'e' ben un motivo se l'impero e' caduto :-)
Ciao
  STeve

 Perché bisogna ancora terminare l'ultima riga con CR LF?
Non ho ben capito cosa intendi con "bisogna".
Io qualche tempo fa volevo scrivere una specie di password in un file e
poi usare la shell openssl per generare l'md5 di quella password, solo che
per qualche cavolo di motivo il vi che uso con cygwin introduceva *da
solo* almeno uno dei due caratteri che hai citato e quindi l'md5 non me lo
calcolava della password ma della password seguita da line feed: l'unica
volta che ho dovuto preferire notepad a vi!
Ciao,
Marco
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 
http://gcc.gnu.org/ml/gcc/2003-11/msg01568.html
Ciao  Manlio

 
http://gcc.gnu.org/ml/gcc/2003-11/msg01568.html
Yup. :)
--
ale
http://ale.riolo.co.uk

 Roba M$ mi sa ... sono eoni che uso il formato Unix :)
Nope, nope, anche su Unix ...
--
ale
http://ale.riolo.co.uk

 Roba M$ mi sa ... sono eoni che uso il formato Unix :)
Credo invece sia roba storica di C.
Non ho sotto mano il K&R, pero' sto lavorando con Python (v.2.7) sotto 
Ubuntu e, per quel poco che ne so, l'unico modo per determinare se si è a 
fine file è verificare se durante la lettura viene restituita una stringa 
vuota (una riga vuota e' una riga del tipo '\n', per cui non c'è 
possibilità di confusione).
-- 
Ciao!
Luca

 possibilità di confusione).
eh?
quindi secondo te in un file di testo non puoi avere stringhe vuote
nel mezzo?

 Qualcuno ha idea se nel 2011 serve ancora veramente a qualcosa? :)
mah afaik non serve a nulla. ricordo che erano i compilatori c che
eoni fa volevano che il sorgente finisse con una linea vuota (che su
unix corrisponde a un \r\r mentre su windows \r\n\r\n) ma è una cosa
che mi era finita nel dimenticatoio...

 mezzo?
No, perche' una riga vuota in mezzo al file è comunque una riga che ha un 
ritorno carrello, variabile a seconda del sistema operativo.
In alcuni casi la funzione è così gentile da tirartelo via (se non 
ricordo male, ReadLine della classe TextReader in C#, ad esempio) in 
altri (Python) l'approccio è un po' piu' di basso livello, per cui ti 
becchi il ritorno carrello (per cui una riga vuota in mezzo a un file ti 
verra' restituita come "\n") e sai che sei a fine file se ti viene 
restituita una stringa vuota del tutto ("").
-- 
Ciao!
Luca

 ritorno carrello, variabile a seconda del sistema operativo.
intanto fai confusione fra il "ritorno carrello" (o cr, carriage
return, ascii 13) e il fine riga (eol), che effettivamente varia da
windows (cr+lf) a unix (cr e basta). ma in ogni caso che c'incastra?
*tutte* le righe terminano con un eol, che sia una riga di mezzo o
l'ultima, come le righe vuote sono costituite dalla sola sequenza eol.
tu hai detto che una riga vuota determina la fine del file, quindi non
rispondi alla domanda come fa un file di testo a contenere righe vuote
al suo interno.

 windows (cr+lf) a unix (cr e basta).
Sotto unix dovrebbe essere lf e basta (codice ascii 10)


Luca Menegotto ha scritto:




Con Python non so (ma mi parrebbe assai strano che le cose stessero come
dici tu), ma in realta' con C, almeno fino a quando ho programmato io, le
varie funzioni, tipo fscanf o fgetc , ecc. dovrebbero restituire EOF nel
caso in cui arrivino alla fine del file, dove EOF e' una costante di
solito definita negli header (spesso pari a -1, almeno con i compilatori
che usavo io).
Poi ci sono altre funzioni, tipo fgets, che, se non ricordo male,
restituiscono NULL quando si arriva a fine file
in questo modo in genere puoi scrivere robe tipo
...
while (fgets(...) != NULL)
{
 <elabora quello che la fgets ha letto>
} //quando il file finisce si esce dal ciclo
...
E in ogni caso, se non si vuole usare direttamente EOF, dovrebbe esserci
una funzione feof che ritorna 1 (o comunque qualcosa di diverso da zero)
se il file e' finito, 0 altrimenti (o qualcosa del genere).
Ciao,
Marco.


 una riga vuota determina la fine del file,
NO!! Ho detto 'stringa vuota', non 'riga vuota'!!!!!! 
Mi dispiace, ma per una volta non hai capito tu, non e' che mi sono 
spiegato male io. Mi quoto:
"unico modo per determinare se si è a 
fine file è verificare se durante la lettura viene restituita una stringa 
vuota (una riga vuota e' una riga del tipo '\n', per cui non c'è 
possibilità di confusione)"
Detto in altro modo: se tu leggi da un file con una readline in Python, 
ti viene restituita una stringa "\n" (sotto Ubuntu), che RAPPRESENTA una 
riga vuota, dal momento che il carattere eol va sempre scartato, ma NON 
E' una stringa vuota.
-- 
Ciao!
Luca

 una funzione feof che ritorna 1 (o comunque qualcosa di diverso da zero)
Se e' per quello, ci sono anche le funzioni tell, che ti dicono dove sei 
nel file.
Il C (NON il C++, quello di K&R, per capirci) e' stato il linguaggio che 
ho amato di piu' in assoluto.
-- 
Ciao!
Luca
-- 
Ciao!
Luca

 ho amato di piu' in assoluto.
Il K&R troneggia sulla mia mensola in sala, però vicino c'é il Stroustrup
(2^ edizione)
PaF nostalgico

 Stroustrup (2^ edizione)
Mannaggia, l'ho prestato e non e' piu' tornato indietro!!!
-- 
Ciao!
Luca

 ho amato di piu' in assoluto.
Anch'io.
Ciao,
Marco


Luca Menegotto ha scritto:



Beh, la seconda edizione comunque e' abbastanza "out of date" (se non
sbaglio sulla seconda edizione non c'era nemmeno la STL o anche se c'era
non era trattata bene). Io ho la terza edizione, ma mi sa che ormai
potrebbe essere "out of date" anche quella (ad esempio di cose tipo boost
non ve ne e' la benche' minima traccia).
Ciao,
Marco


 Beh, la seconda edizione comunque e' abbastanza "out of date"
Ma un libro del genere si tiene per motivi affettivi!!
Io ho ancora il Grogono (Programming in Pascal)...
-- 
Ciao!
Luca

 E' una stringa vuota.
sarò io che non capisco ma per quanto rilegga queste quattro righe non
vedo proprio la spiegazione a quanto scrivi sopra. ti ripongo le
domande in modo secco: secondo te tutti i file devono terminare con
'\n'? e se nel mezzo del file metti una sequenza multipla di lf '\n\n'
ovvero stringhe vuote (per me sono righe vuote, ma chiamiamole pure
come vuoi tu) secondo te il file viene troncato?

 come vuoi tu) secondo te il file viene troncato?
No.
OK. Un po' di teoria di base.
Per definizione, una stringa e' una sequenza di caratteri; quando dico
questo, intendo QUALSIASI carattere, compreso '\n'. Una stringa vuota
è una stringa che ha lunghezza zero, ossia una stringa che al suo
interno non ha alcun carattere, nemmeno '\n'; questo significa che una
stringa "\n" non è una stringa vuota, dal momento che al test della
lunghezza il risultato non e' 0 ma 1.
Quanto detto sopra implica che una riga di file di testo vuota NON E'
una stringa vuota, ma una stringa di lunghezza 1 (2 se sotto Windows)
che ha come unico componente il solo terminatore di linea.
Nel caso da te proposto, dal momento che la readline di un oggetto
file di Python mi restituisce, per ogni riga valida, una stringa
composta dalla riga di testo eventualmente presente E, in ogni caso,
dal terminatore di riga ('\n'),  otterrei:
readline 1
valore restituito: "\n" (riga di testo vuota)
readline 2
valore restituito: "\n" (riga di testo vuota)
readline 3
valore restituito: ""  (stringa vuota, sono a fine file).
Spero ora sia piu' chiaro. Se vuoi avere un'idea di cosa succede in un
file di testo, comunque, aprilo con un editor esadecimale.
--
Ciao!
Luca

 OK. Un po' di teoria di base.
lasciamo perdere, l'hai detto te di non fare i maestrini e se vogliamo
dare delle lezioni cerchiamo di essere almeno corretti :P
il terminatore di stringa nel c è il carattere 0x00, una "stringa
vuota" è un array di caratteri che ha il terminatore nella prima
posizione. quindi se tu dici che una stringa vuota determina la fine
del file mi aspetto che alla fine del file mi trovo un terminatore o
una sequenza di terminatori, giusto? in realtà non è così, i file non
finiscono con una sequenza particolare di byte e più in generale la
fine del file *non* *è* determinata dal suo contenuto bensì è scritta
nella struttura della directory (o comunque è una informazione che
viene astratta dal file system). che ci siano funzioni di lettura che
a fine file restituiscano stringa vuota non vuol dire nulla, la
fgets() restituisce null mentre la  fgetc() restituisce -1, per dire.

 fgets() restituisce null mentre la  fgetc() restituisce -1, per dire.
Ancora, mi spieghi dove avrei affermato il contrario? Sei tu che hai
continuato a parlare di fantomatici troncamenti a meta' file, e io
continuo a dirti che non c'è possibilità comunque di confusione.
Nota peraltro che, chiamalo -1 (EOF), chiamalo null, chiamalo stringa
vuota o mancanza di terminatore di riga, è in ogni caso un valore
simbolico che indica una particolare condizione che non si verifica
durante la normale lettura del file. E', in altri termini, una
convenzione, come è una convenzione TUTTO in informatica, bit esclusi
(dalla lunghezza di un byte alla struttura di un file system).
--
Ciao!
Luca

 testo vuota corrisponde a "\n", ossia 0A00.
Mannaggia alla fretta!!
Tira via il NON, che come sopra non ha senso.
--
Ciao!
Luca

 corte. ;-)
allora mi sa che è venuto il momento di dargli una ripassata, visto
che io le braghe corte le portavo a inizi anni 70 :P

 che io le braghe corte le portavo a inizi anni 70 :P
Ah, ma allora sei un vecchietto anche tu!!!! :-DDDD
-- 
Ciao!
Luca

 che io le braghe corte le portavo a inizi anni 70 :P
30 post sull'eof : che nerds. (detto scuotendo la testa)
:-))

 (dalla lunghezza di un byte alla struttura di un file system).
Questo e' vero, ma dai tuoi primi post sembrava che tu dicessi che il file
deve terminare con una "riga vuota" (o stringa vuota) affinche' se ne 
raggiunga la fine.


 30 post sull'eof : che nerds. (detto scuotendo la testa)
Se poi mi spieghi che c'e' di male a cazzeggiare un po'...
E nota, senza metterci Berlusconi, nemmeno una volta!!!
;-)
-- 
Ciao!
Luca

 (dalla lunghezza di un byte alla struttura di un file system).
Difatti, per quanto poco abbia fatto programmazione, secondo me
l'equivoco (che sta generando un dozzilione di post) nasce dal fatto che
non si stanno facendo adeguati distinguo tra il discorso dell'effettivo
contenuto del file di testo e quel che restituiscono le funzioni dei
vari linguaggi.
bye G.L.
-- 
Da i.d.c.tutela:
P.S. Quando ci sarà lo switch-off, avrò problemi anche col
monitor del PC? Ho visto che è collegato in modalità analogica.

 Equinozio wrote:


Beh... ora ce lo hai messo :-)
Il "presidente programmatore" ?!
