Add linefeed and carriage return characters on the last line.
Alessandro Riolo
È 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? :)
STeve
wrote:
> 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
Alessandro Riolo
> 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',
No, no, alla fine del file. Nel mio caso era un header, ma mi è
capitato n mila volte con file c, cpp, rc e così via.
Perché bisogna ancora terminare l'ultima riga con CR LF?
> :-)
Sai che i Romani scrivevano proprio così :)
STeve
wrote:
> No, no, alla fine del file. Nel mio caso era un header, ma mi è
> capitato n mila volte con file c, cpp, rc e così via.
Roba M$ mi sa ... sono eoni che uso il formato Unix :)
> Sai che i Romani scrivevano proprio così :)
C'e' ben un motivo se l'impero e' caduto :-)
Ciao
STeve
Marcoxxx
> 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
Manlio Perillo
> È 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).
>
http://gcc.gnu.org/ml/gcc/2003-11/msg01568.html
Ciao Manlio
Alessandro Riolo
wrote:
> http://gcc.gnu.org/ml/gcc/2003-11/msg01568.html
Yup. :)
Alessandro Riolo
> Roba M$ mi sa ... sono eoni che uso il formato Unix :)
Nope, nope, anche su Unix ...
Luca Menegotto
> 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
rootkit
> > 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).
eh?
quindi secondo te in un file di testo non puoi avere stringhe vuote
nel mezzo?
rootkit
> È 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? :)
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...
Luca Menegotto
> quindi secondo te in un file di testo non puoi avere stringhe vuote nel
> 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
rootkit
> > quindi secondo te in un file di testo non puoi avere stringhe vuote nel
> > mezzo?
>
> No, perche' una riga vuota in mezzo al file è comunque una riga che ha un
> 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.
Marcoxxx
[SNIP]
> 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).
Sotto unix dovrebbe essere lf e basta (codice ascii 10)
Marcoxxx
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.
Luca Menegotto
> intanto fai confusione fra il "ritorno carrello"
Nessuna confusione, l'importante è capirsi.
O pensi davvero che stiamo a fare i maestrini?
> ascii 13) e il fine riga (eol), che effettivamente varia da windows
> (cr+lf) a unix (cr e basta).
Ricordo male io o in Unix non e' cr ma lf il carattere eol? Che se non
ricordo male, e' solo nei Mac che viene impiegato cr come fine riga.
> ma in ogni caso che c'incastra? *tutte* le
> righe terminano con un eol, che sia una riga di mezzo o l'ultima
Mica vero, ed e' il senso del post iniziale di Alessandro e della mia
risposta. Ancora oggi ci sono editor (Kate, ad esempio) che, se tu non ce
lo metti in modo esplicito, non aggiungono l'eol all'ultima riga del file.
> le righe vuote sono costituite dalla sola sequenza eol. tu hai detto che
> 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
Luca Menegotto
> Con Python non so (ma mi parrebbe assai strano che le cose stessero come
> dici tu),
Mettiamola cosi'. Io sono abbastanza inesperto in Python, ma tutti gli
esempi che ho trovato, per valutare la fine file, fanno quel che ho detto
io. Poi, probabilmente, c'e' qualche altro modo.
> 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).
Astraendola, e' comunque un modo univoco per indicare una determinata
condizione. Basterebbe che io definissi una costante simbolica EOF = '',
ed ecco che anch'io potrei verificare la condizione EOF...
> 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 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
PaF
> Il C (NON il C++, quello di K&R, per capirci) e' stato il linguaggio che
> ho amato di piu' in assoluto.
Il K&R troneggia sulla mia mensola in sala, però vicino c'é il Stroustrup
(2^ edizione)
PaF nostalgico
Luca Menegotto
> Il K&R troneggia sulla mia mensola in sala, però vicino c'é il
> Stroustrup (2^ edizione)
Mannaggia, l'ho prestato e non e' piu' tornato indietro!!!
--
Ciao!
Luca
Marcoxxx
> Astraendola, e' comunque un modo univoco per indicare una determinata
> condizione. Basterebbe che io definissi una costante simbolica EOF = '',
> ed ecco che anch'io potrei verificare la condizione EOF...
Si, ma dipende da quale evento fa si che la funzione "di libreria"
restituisca EOF, qualsiasi sia il suo valore (a parte che in genere le
funzioni che restituiscono EOF hanno un prototipo del tipo
int <nome_funzione> (<parametri>)
per cui fargli restituire '' potrebbe creare qualche problema)
> > 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 e' per quello, ci sono anche le funzioni tell, che ti dicono dove sei
> nel file.
Io ho il sospetto che l'implementazione delle funzioni che ritornano EOF
usi qualcosa di simile alla ftell per restituire EOF quando sei oltre
l'ultima posizione "buona" del file, ma appunto questo e' solo un
sospetto, non so se sia cosi'.
> Il C (NON il C++, quello di K&R, per capirci) e' stato il linguaggio che
> ho amato di piu' in assoluto.
Anch'io.
Ciao,
Marco
Marcoxxx
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
Luca Menegotto
> 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
rootkit
> > intanto fai confusione fra il "ritorno carrello"
>
> Nessuna confusione, l'importante è capirsi.
> O pensi davvero che stiamo a fare i maestrini?
sto discutendo per cercare di capire.
> > ascii 13) e il fine riga (eol), che effettivamente varia da windows
> > (cr+lf) a unix (cr e basta).
>
> Ricordo male io o in Unix non e' cr ma lf il carattere eol?
ricordi bene, ho confuso io.
> 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.
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?
Luca Menegotto
> sarò io che non capisco ma per quanto rilegga queste quattro righe non
> vedo proprio la spiegazione a quanto scrivi sopra.
Perche', ho dedotto, pensi che 'stringa vuota' e 'riga di file di
testo vuota' siano la stessa cosa; non e' cosi', vedi oltre.
> ti ripongo le
> domande in modo secco: secondo te tutti i file devono terminare con
> '\n'?
Non necessariamente, vedi il riferimento a Kate; viceversa, se usi vi,
il fine linea ti viene aggiunto anche a fine file. E' proprio il fatto
che non puoi presumerlo l'inghippo.
> 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?
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
rootkit
> No.
>
> 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.
Luca Menegotto
> una "stringa
> vuota" è un array di caratteri che ha il terminatore nella prima
> posizione.
Se mi indichi dove ho detto il contrario, ti sono grato.
Il fatto incontrovertibile è che se usi ad esempio strlen su una
sequenza di bytes 0A 00 la lunghezza restituita è 1, mentre se hai
semplicemente 00, la lunghezza e' 0.
> 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?
NO!!!
Io ho detto che se leggo un file con Python, uno dei modi per
determinare se NON sono a fine file è verificare se la stringa
restituita sia "", ossia 00, ed e' un test valido perché una riga di
testo vuota corrisponde a "\n", ossia 0A00.
Lo dico in altro modo: la specifica è: readline restituisce una riga
di testo, compreso il terminatore; se restituisce riga vuota (o, per
la verita', una riga senza terminatore), sei a fine file.
http://docs.python.org/library/stdtypes.html
> 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).
Giovane, io giocavo coi files e col C quando tu avevi ancora le braghe
corte. ;-)
Scherzi a parte, quanto stai dicendo e' ovvio a chiunque abbia almeno
una conoscenza seppur superficiale di come funziona un file system. Ma
non stavamo parlando di questo.
> 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.
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
Luca Menegotto
> Io ho detto che se leggo un file con Python, uno dei modi per
> determinare se NON sono a fine file è verificare se la stringa
> restituita sia "", ossia 00, ed e' un test valido perché una riga di
> testo vuota corrisponde a "\n", ossia 0A00.
Mannaggia alla fretta!!
Tira via il NON, che come sopra non ha senso.
--
Ciao!
Luca
rootkit
> Giovane, io giocavo coi files e col C quando tu avevi ancora le braghe
> 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
Luca Menegotto
> allora mi sa che č venuto il momento di dargli una ripassata, visto
> che io le braghe corte le portavo a inizi anni 70 :P
Ah, ma allora sei un vecchietto anche tu!!!! :-DDDD
--
Ciao!
Luca
Equinozio
> che io le braghe corte le portavo a inizi anni 70 :P
30 post sull'eof : che nerds. (detto scuotendo la testa)
:-))
Marcoxxx
> Lo dico in altro modo: la specifica č: readline restituisce una riga
> di testo, compreso il terminatore; se restituisce riga vuota (o, per
> la verita', una riga senza terminatore), sei a fine file.
> http://docs.python.org/library/stdtypes.html
[SNIP]
> 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).
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.
Luca Menegotto
> 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
Renaissance
> 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).
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.
Marcoxxx
> Equinozio wrote:
Beh... ora ce lo hai messo :-)
Il "presidente programmatore" ?!