Newsgroup: it.comp.lang.c
Titolo: CTRL-Z e EOF

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


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


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: 
+3902 9679 9655
* Fax: 
+3902 9679 9373
* e-mail: 
enrico....@fatti.com
* 
http://www.fatti.com
***********************************************************

 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

 su cui e' riferito come targhet ???
che io sappia no...

"FRaNCeSCo" <?@?.?> ha scritto nel messaggio
news:2vhWa.8735$cl3.2...@news2.tin.it...

come mai all'ora tutti i programmi portabili per terminale usano /n sia per
*nix / mac / win ???
ciao

 /n sia per *nix / mac / win ???
Casomai useranno \n ;)
Ciao,
-- 
+--------+ ASCII ribbon campaign ( )
|  kral  |  - against HTML email  X 
+--------+              & vCards / \

 Casomai useranno \n ;)
dai ho schiacciato lo / piu' vicino ... me son sbaya !!!
ciao

"FRaNCeSCo" <?@?.?> ha scritto nel messaggio
news:2vhWa.8735$cl3.2...@news2.tin.it...

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

scritto con \n viene generata la giusta terminazione di linea dos CR LF,
   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.
-- 
S.L.

su cui e' riferito come targhet ???
Sě.
-- 
Andrea Laforgia
Open Delphi Manual
http://groups.yahoo.com/group/delphi_open_manual/

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.


 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

 se è stata stabilita la convenzione di leggere come file di testo.
grande hai chiuso il discorso dicendo tutto :-)
ciao

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.


 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

un 0x0a ? 
Il ritorno a capo ha senso solo se stai parlando di file di testo.


 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

ma hai letto la domanda ???
Sei tu che devi leggere le risposte.


se è stata stabilita la convenzione di leggere come file di testo.
   E hai ragione. Chissa` che avevo in testa. :)
-- 
S.L.

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.
