CTRL-Z e EOF

[antiulano]

ciao a tutti

mi sto avvicinando al C studiando dal KR e usando il gcc sotto Win98

a pag.19 del KR c'è un programma che conta le linee di input, di cui riporto
la parte principale

while((c=getchar())!=EOF)
if (c=='\n')
nl++;
printf("Numero linee: %d", nl);

ora se scrivo:
asdfadsfadsfadsfa (a capo)
adsfadsfadsfadfasa (e un altro a capo)
e CTRL - Z
tutto bene. L'output è: "Numero linee: 2"

ma se scrivo:
asdfasdfadsfasfa (a capo)
asdfadsfasdfadsfsa (CTRL-Z)... pensavo che il programma dovesse terminare...
invece devo ancora...
CTRL - Z
e l'output è: Numero linee: 1...

Non mi aspettavo certo che contasse 2 linee (la condizione è c=='\n') ma che
il programma terminasse alla seconda linea.

La domanda e': Che cos'è nella seconda prova, il primo CTRL-Z ? come mai non
viene visto come un EOF???

Grazie

[FRaNCeSCo]

Post by antiulano
Non mi aspettavo certo che contasse 2 linee (la condizione è c=='\n') ma che
il programma terminasse alla seconda linea.

vai a debuggare un po'...
cmq penso che il programma elabori la getchar quando svuota il buffer e cioè
quando gli dai un ritorno a capo o finisce il file....

ciao

Fra

[Enrico Migliore]

Post by antiulano
ciao a tutti
mi sto avvicinando al C studiando dal KR e usando il gcc sotto Win98
a pag.19 del KR c'è un programma che conta le linee di input, di cui riporto
la parte principale
while((c=getchar())!=EOF)
if (c=='\n')
nl++;
printf("Numero linee: %d", nl);
asdfadsfadsfadsfa (a capo)
adsfadsfadsfadfasa (e un altro a capo)
e CTRL - Z
tutto bene. L'output è: "Numero linee: 2"
asdfasdfadsfasfa (a capo)
asdfadsfasdfadsfsa (CTRL-Z)... pensavo che il programma dovesse terminare...
invece devo ancora...
CTRL - Z
e l'output è: Numero linee: 1...
Non mi aspettavo certo che contasse 2 linee (la condizione è c=='\n') ma che
il programma terminasse alla seconda linea.
La domanda e': Che cos'è nella seconda prova, il primo CTRL-Z ? come mai non
viene visto come un EOF???
Grazie

ciao,

asdfasdfadsfasfa (a capo)
asdfadsfasdfadsfsa (CTRL-Z)... pensavo che il programma dovesse terminare...

la seconda stringa non e' terminata correttamente da un carattere '\n'.
Ricorda inoltre una cosetta che il carattere di fine riga e' dipendente
dal filesystem:

WINDOWS: \r\n (ben due caratteri!!)
UNIX: \n
MAC: \r

ogni filesystem termina le righe come vuole.

ciao
Enrico
--
***********************************************************
* Enrico Migliore - Co-founder and Senior Software Engineer
* FATTI srl - The Service Gateway Company
* Via Donatello 48 - 20020 - Solaro - Milano - Italy
* Phone: [phone]
* Fax: [phone]
* e-mail: ***@fatti.com
* http://www.fatti.com
***********************************************************

[Goul_duKat]

Post by Enrico Migliore
WINDOWS: \r\n (ben due caratteri!!)
UNIX: \n
MAC: \r
ogni filesystem termina le righe come vuole.

lo \n non viene convertito opportunatamente dal compilatore a seconda del SO
su cui e' riferito come targhet ???

se non mi sbaglio mi pare di averlo letto pure sul libro Think in C++ che
sto finendo ora ...

se fosse vero quello che sto dicendo io forse e' meglio parlagli di CR e NL
che non degli escape che poi potrebbe far casino usandoli magari in modo
sbagliato ?

ciao

[FRaNCeSCo]

Post by Goul_duKat
lo \n non viene convertito opportunatamente dal compilatore a seconda del SO
su cui e' riferito come targhet ???

che io sappia no...

[Goul_duKat]

Post by FRaNCeSCo

Post by Goul_duKat
lo \n non viene convertito opportunatamente dal compilatore a seconda

del

Post by FRaNCeSCo
SO

Post by Goul_duKat
su cui e' riferito come targhet ???

che io sappia no...

come mai all'ora tutti i programmi portabili per terminale usano /n sia per
*nix / mac / win ???

ciao

[kral]

/n sia per *nix / mac / win ???

Casomai useranno \n ;)

Ciao,

[Goul_duKat]

Post by kral

/n sia per *nix / mac / win ???

Casomai useranno \n ;)

dai ho schiacciato lo / piu' vicino ... me son sbaya !!!

ciao

[Goul_duKat]

Post by FRaNCeSCo

Post by Goul_duKat
lo \n non viene convertito opportunatamente dal compilatore a seconda

del

Post by FRaNCeSCo
SO

Post by Goul_duKat
su cui e' riferito come targhet ???

che io sappia no...

ora ti posso dire che il gcc quando gli dai in pasto lo \n genera' il giusto
terminatore di linea per ogni ambiente ... infatti ho visto ora in un file
scritto con \n viene generata la giusta terminazione di linea dos CR LF,
quindi ne deduco che quello che ho letto sul libro sia vero e che quindi
basta usare sempre \n che poi ci pensa il compilatore a renderlo portabile
su tutte le architetture.

ciao

[Goul_duKat]

Pero` se provi a leggere un carattere alla volta con getc, vedrai
che ti restituira prima un '\r' e poi un '\n' in due letture
consecutive, anche se lo apri come testo.

si stavo parlando di scrittura non di lettura ... cmq se poi sul mac la
terminazione e' \r quando si fanno i get che terminano di default allo \n
loro avranno il default sullo \r ???

ciao

[Andrea Laforgia]

On Sat, 2 Aug 2003 19:12:17 +0200, "Goul_duKat"

Post by Goul_duKat
si stavo parlando di scrittura non di lettura ...

Vale per entrambi i casi. Quando si apre un file in modalità testo si
sta dicendo al sistema che, in lettura, la sequenza di caratteri che
rappresenta l'"a capo" deve essere tradotta in un unico carattere '\n'
(che corrisponde al carattere ASCII 0x0a, per scelta).

In scrittura si sta ugualmente dicendo che '\n' deve essere tradotto
nella sequenza di caratteri che *su quel sistema* rappresenta l'"a
capo" (e che sotto DOS è una sequenza 0x0d 0x0a, sotto Mac un 0x0d e
sotto Unix/Linux 0x0a).

E` per questo che, lavorando sotto gli Unix-like, non esiste la
differenza tra file di testo e i cosiddetti file binari.

[Goul_duKat]

Post by Andrea Laforgia
Vale per entrambi i casi. Quando si apre un file in modalità testo si
sta dicendo al sistema che, in lettura, la sequenza di caratteri che
rappresenta l'"a capo" deve essere tradotta in un unico carattere '\n'
(che corrisponde al carattere ASCII 0x0a, per scelta).
In scrittura si sta ugualmente dicendo che '\n' deve essere tradotto
nella sequenza di caratteri che *su quel sistema* rappresenta l'"a
capo" (e che sotto DOS è una sequenza 0x0d 0x0a, sotto Mac un 0x0d e
sotto Unix/Linux 0x0a).
E` per questo che, lavorando sotto gli Unix-like, non esiste la
differenza tra file di testo e i cosiddetti file binari.

quindi mi stai anche dicendo che i vari printf e scanf (ecc) quando nella
sequenza gli dai uno \n si vanno a vedere il tipo di apertura del file e se
testo convetono in formato giusto, e se binario invece scrivono normalmente
un 0x0a ? questo porta un grosso appesantimento delle conversioni di
stringhe in dos/mac !!!

ciao

[Goul_duKat]

Post by Goul_duKat
quindi mi stai anche dicendo che i vari printf e scanf (ecc) quando nella
sequenza gli dai uno \n si vanno a vedere il tipo di apertura del file e se
testo convetono in formato giusto, e se binario invece scrivono normalmente
un 0x0a ?

Il ritorno a capo ha senso solo se stai parlando di file di testo.

ma hai letto la domanda ???
ti ho chiesto se le funzioni si vanno a vedere dasole il tipo di apertura
del file e fanno le conversioni loro, e non il compilatore ...

ciao

[Goul_duKat]

Pero` se provi a leggere un carattere alla volta con getc, vedrai
che ti restituira prima un '\r' e poi un '\n' in due letture
consecutive, anche se lo apri come testo.

Stai confondendo. '\n' è un'astrazione per "a capo", non implica
nulla su quanti e quali caratteri siano coinvolti nella
rappresentazione di questo "a capo". Sotto Unix, '\n' si tradurrà in
un carattere 0x0a, sotto Windows in una coppia 0x0d 0x0a, sotto
Macintosh in 0x0d, e così via...
La sequenza di escape ha valore sia in ingresso che in uscita, ma solo
se è stata stabilita la convenzione di leggere come file di testo.

grande hai chiuso il discorso dicendo tutto :-)

ciao

[S.L.]

La sequenza di escape ha valore sia in ingresso che in uscita, ma solo
se è stata stabilita la convenzione di leggere come file di testo.

E hai ragione. Chissa` che avevo in testa. :)

[Andrea Laforgia]

On Thu, 31 Jul 2003 23:18:29 +0200, "Goul_duKat"

Post by Goul_duKat
lo \n non viene convertito opportunatamente dal compilatore a seconda del SO
su cui e' riferito come targhet ???

Sì.

[Enrico Migliore]

Laforgia ha fatto chiarezza:

"Stai confondendo. '\n' è un'astrazione per "a capo", non implica
nulla su quanti e quali caratteri siano coinvolti nella
rappresentazione di questo "a capo". Sotto Unix, '\n' si tradurrà in
un carattere 0x0a, sotto Windows in una coppia 0x0d 0x0a, sotto
Macintosh in 0x0d, e così via...

La sequenza di escape ha valore sia in ingresso che in uscita, ma solo
se è stata stabilita la convenzione di leggere come file di testo."


Per vedere come il S.O. traduce '\n' basta aprire un file
testo in lettura con modalita' binaria:

pippo = fopen("miofile","rb");

e fare un parse carattere dopo carattere alla ricerca
di token di due caratteri ('\r' '\n') oppure di
un carattere solo ('\n') oppure ('\r');

Una cosa posso dirvi per certo: la sostituzione di '\n'
con la sequenza '\r''\n' e' fatta dalla stdio library
e non dal filesystem. Questo lo so perche' ho lavorato
per 6 mesi sulla libreria stdio di Minix.

ciao
Enrico
--
***********************************************************
* Enrico Migliore - Co-founder and Senior Software Engineer
* FATTI srl - The Service Gateway Company
* Via Donatello 48 - 20020 - Solaro - Milano - Italy
* Phone: [phone]
* Fax: [phone]
* e-mail: ***@fatti.com
* http://www.fatti.com
***********************************************************