Newsgroup: it.comp.os.linux.iniziare
Titolo: EOF e' un carattere?

sento spesso dire che EOF e' un carattere... il carattere di fine file.
ma io posso scrivere tutti e 256 i caratteri in un file, da 00 a FF, 
senza per questo mai decretarne la fine anticipata...
quindi e' solo un modo di dire?

Antonio Macchi wrote:

grosso modo sì
http://en.wikipedia.org/wiki/End-of-file
http://en.wikipedia.org/wiki/End-of-transmission_character

 ma io posso scrivere *tutti e 256* i caratteri in un file, da 00 a FF,
ehm... non vorrei darti una brutta notizia, ma siamo nel 2009. E' da
mo' che praticamente tutti i sistemi operativi implementano caratteri
multibyte...
bye!

 multibyte...
chiaro.
pero' questo significa che non viene veramente "letto"... non c'e' 
nessun carattere EOF da nessuna parte in nessun file
i file non finiscono perche' alla fine c'e' un carattere speciale
e' il sistema che sa quanto e' lungo, e che, se si tenta di leggere 
oltre la sua lunghezza, invia quello che si potrebbe definire un 
"messaggio d'errore"...
sempre se ho capito giusto

 nessun carattere EOF da nessuna parte in nessun file
Ovviamente no, perche' EOF e' definito come NEGATIVO (!) mentre i
caratteri sono tutti positivi. Quello che succede e' che il sistema
'crea' un segnale di fine-file quando raggiunge la fine (ed il
filesystem dice che il file e' finito) o quando la connessione viene
chiusa se stai leggendo da una pipe o da un socket.
Eof e' un carattere "virtuale".
Davide

 Eof e' un carattere "virtuale".
eh... com'e' dura la vita!
:)

 sempre se ho capito giusto
Si hai capito bene. Non viene scritto nessun carattere di EOF nel file. Il 
sistema e' in grado di riconoscere la fine del file (altrimenti che file 
system sarebbe :-)).
Se da stdin l'EOF si assume essere ctrl+D (il sistema non puo' sapere quando 
ho finito di scrivere d tastiera).
Ciao
-- 
 ************** (.)_(.) *******************
 Un amico � uno che sa tutto di te e,
 nonostante questo, gli piaci
(E. Hobbard) 

 quando ho finito di scrivere d tastiera).
che poi la cosa e' ancora piu' strana... i Ctrl+[A-Z] sono, se non 
sbaglio, un modo per inviare i carateri ascii da 1 a 24
tipo:
Ctrl-A = 1
Ctrl-B = 2
Ctrl-C = 3
Ctrl-D = 4 <- End Of Line
non tutti riesco a vederli, ma molti si, e quindi vado per deduzione
guarda:
$ read -n1
^A
$ hd <(echo -n $REPLY)
00000000  01                                                |.|
00000001
$ read -n1
^B
$ hd <(echo -n $REPLY)
00000000  02                                                |.|
00000001
salto ^C e ^D che mi chiudono read senza lasciare niente...
$ read -n1
^E
$ hd <(echo -n $REPLY)
00000000  05                                                |.|
00000001
o, per dire... il carattere ascii 7, che e' indicato come BELL...
$ read -n1
^G
$ echo $REPLY
... e senti (se l'hardware ti funziona) la campanella
pero' se mando il carattere ascii 04 a read, mica smette di leggere
$ echo -n $'\x04' | { read; hd <(echo -n $REPLY); }
00000000  04                                                |.|
00000001
e' come se questi programmatori ci stessero prendendo per il culo...
:)
ciao

 00000001
Perche' non e' read che lo legge. E' il terminale che lo intercetta.
# stty -a
speed 38400 baud; rows 50; columns 157; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D;
[snip]
nota il eof = ^D
Siccome quando read legge lo standard input e' connesso al terminale, e' il 
driver del terminale (nel kernel) che, quando riceve ^D da tastiera, manda 
un pseudo end-of-file alla system call che sta leggendo (presumibilmente una 
read()), la quale ritornera' con 0 che significa appunto end of file.

 read()), la quale ritornera' con 0 che significa appunto end of file.
e un po' piu' di luce fu!
infatti su stty -a sono indicati tutti i ^[A-Z] che non si riescono a 
leggere
thanks

 read()), la quale ritornera' con 0 che significa appunto end of file.
infatti, usando la combinazione ^V^[A-Z] si bypassa questo comportamento 
e si puo' visualizzare anche quei caratteri
$ read
^C
$ hd <(echo -n $REPLY)
00000000  03                                                |.|
00000001
$ read
^D
$ hd <(echo -n $REPLY)
00000000  04                                                |.|
00000001
tuttavia la cosa non e' possibile usando il parametro -n di read
sembra che il ^V sia usato in modo diverso da read quando usa -n, e 
quando non lo usa
forse e' un piccolo bug della shell...
comunque grazie ancora per la spiegazione
ciao

 forse e' un piccolo bug della shell...
No secondo me e' semplicemente che con -n read deve terminare quando e' 
stato letto il numero di caratteri specificato, che richiede un maggior 
controllo sul terminale, e quindi probabilmente la shell fa qualche system 
call per cambiare qualche attributo del terminale (non ho provato, ma penso 
che sia verosimile).

 che sia verosimile).
infatti mi chiedevo... come si fa in C a simulare una read -n1?
tutte le funzioni di stdio che leggono aspettano fine riga o fine file
ora capisco che e' piu' complicato di quel che credevo...

 che sia verosimile).
e infatti... questa e' stata la risposta di chet ramey
When using the -n option, bash puts the terminal into character-at-a-time
non-canonical mode, which disables the tty special characters.  When
using read without that option, the terminal stays in canonical mode and
does erase, kill, and literal-next processing.

 questo che dici e' fuorviante
]zac[
No, sei tu che ai autoforvi da solo, non leggendo che chiaramente il
soggetto della risposta è IL SISTEMA, e non IL CONTENUTO DEL FILE:
Per esempio , c'è una funzione che legge i dati dal file, la funzione,
quando è finito il file, invia un carattere EOF (virtuale).
P.S. Dovresti leggere con molta più attenzione le risposte, e sforzandoti di
più di capirle.