echo e cat: che differenza c'e`?
Andrea Celli
convinto che i due comandi:
$ echo qualcosa > pippo
$ echo qualcosa | cat > pippo
producessero esattamente lo stesso risultato.
Adesso devo inviare "qualcosa" ad un dispositivo connesso
alla seriale e
$ echo qualcosa > /dev/ttyS0 NON funziona
$ echo qualcosa | cat > /dev/ttyS0 _funziona_
$ cat file_con_scritto_qualcosa > /dev/ttyS0 _funziona_
Qualcuno sa spiegarmene il perche'?
C'e` una differenza reale tra questi comandi?
E` un problema legato alla porta seriale?
ciao, Andrea
PS. ho provato a mettere dopo qualcosa i
caratteri di fine riga, ritorno carrello, ...
kaile...@tiscalinet.it
> Crogiolandomi nella mia beata ignoranza, sono stato sempre
> convinto che i due comandi:
> $ echo qualcosa > pippo
> $ echo qualcosa | cat > pippo
> producessero esattamente lo stesso risultato.
>
> Adesso devo inviare "qualcosa" ad un dispositivo connesso
> alla seriale e
>
> $ echo qualcosa > /dev/ttyS0 NON funziona
Da me funziona...
>
> $ echo qualcosa | cat > /dev/ttyS0 _funziona_
Un doppione, mai provato...
>
> $ cat file_con_scritto_qualcosa > /dev/ttyS0 _funziona_
Normale...
>
> Qualcuno sa spiegarmene il perche'?
> C'e` una differenza reale tra questi comandi?
Sperando di non dire vaccate, echo "stampa" tutto così com'è, cat lo fa in
modalità raw (byte per byte?)
> E` un problema legato alla porta seriale?
Bella domanda ma visto che da me echo qualcosa > /dev/ttyS0 funziona.......
Lo so, ti ho aiutato poco, probabilmente ho scritto anche qualche
stupidata, ma almeno non ti sentirai solo:-))
Ciao.
--
*** Per E-mail rimuovi ModE dall'indirizzo ***
*** Linux user # 198661 --- ICQ 33500725 ***
*** homepage http://web.tiscalinet.it/kailed ***
*** Powered by Linux ***
rez
>Crogiolandomi nella mia beata ignoranza, sono stato sempre
>convinto che i due comandi:
>$ echo qualcosa > pippo
>$ echo qualcosa | cat > pippo
>producessero esattamente lo stesso risultato.
E perche', hai mai visto com'e` diverso, da ex, dare:
:r file | grep boh
che non funge, ed invece :r!cat file |grep boh ?
Cmq con echo non c'entrera` la storia di escape? Prova con -e.
D'altra parte [visto che a Daniele va] da certi, echo e` built-in.
--
Ci sentiamo | Remigio Zedda || Attenzione! campo "From:" alterato
ciao Remigio | ||==> E-mail: remi...@tiscalinet.it
-------------| ..si` d'accordo.. ma con la Deb e` un'altra cosa!
/* Linux 2.2.17 su Debian GNU/Linux 2.2 Potato */
NicoKid
dicendo...
> Andrea Celli wrote:
cut............
> > Adesso devo inviare "qualcosa" ad un dispositivo connesso
> > alla seriale e
> >
> > $ echo qualcosa > /dev/ttyS0 NON funziona
> Da me funziona...
Da me pure.
Nicola.
--
______________________________
chi va pian va san e va lontan
Andrea Celli
>
> On Tue, 17 Apr 2001 14:37:55 +0200, Andrea Celli wrote:
> >Crogiolandomi nella mia beata ignoranza, sono stato sempre
> >convinto che i due comandi:
> >$ echo qualcosa > pippo
> >$ echo qualcosa | cat > pippo
> >producessero esattamente lo stesso risultato.
>
>
> Cmq con echo non c'entrera` la storia di escape? Prova con -e.
> D'altra parte [visto che a Daniele va] da certi, echo e` built-in.
>
Posso provarci.
Sarebbe come se echo inviasse "qualcosa" seguito da una newline
(cosi` dice il man) e che il cat ci aggiunga un EOF o qualcosa
di simile che dovrei aggiungere io a mano.
O ti ho capito male?
La cosa strana e` che i due comandi precedenti mi generano
due file pippo esattamente identici anche leggendoli
in esadecimale.
Con hexedit dovrei vedere anche i caratteri di controllo.
O sbaglio?
ciao, Andrea
Andrea Celli
>
> Sorseggiando il suo prosecco Dan...@kailed.kailed.net, si rivolse al NG
> dicendo...
>
> > Andrea Celli wrote:
>
> cut............
> > > Adesso devo inviare "qualcosa" ad un dispositivo connesso
> > > alla seriale e
> > >
> > > $ echo qualcosa > /dev/ttyS0 NON funziona
> > Da me funziona...
>
> Da me pure.
>
Non so cosa dirvi, il mio dispositivo deve aver bevuto una
botte di Recioto Amarone, ma col semplice echo non
reagisce. :-)
Forse ha ragione Remigio e salta qualche carattere di controllo
che a voi non da` problemi, ma a me si. :-(
ciao, andrea
ema
> $ echo qualcosa > /dev/ttyS0 NON funziona
>
> $ echo qualcosa | cat > /dev/ttyS0 _funziona_
>
> $ cat file_con_scritto_qualcosa > /dev/ttyS0 _funziona_
>
Il primo ha in meno un ritorno a capo... se in qualcosa metti alla fine
\n (o \r\n, nonzo) diventano tutti assolutamente identici.
bye!
--
Emanuele Cesena Attenzione! penguinpowered è morto :-/
<ece...@libero.it> - rimuovi XXX x rispondere
Andrea Celli
>
> Mio cuggino mi ha detto che Andrea Celli <ce...@iac.rm.cnr.it> scrisse:
> > $ echo qualcosa > /dev/ttyS0 NON funziona
> >
> > $ echo qualcosa | cat > /dev/ttyS0 _funziona_
> >
> > $ cat file_con_scritto_qualcosa > /dev/ttyS0 _funziona_
> >
> gli ultimi 2 sono assolutamente identici.
infatti fungono entrambi bene.
> Il primo ha in meno un ritorno a capo... se in qualcosa metti alla fine
> \n (o \r\n, nonzo) diventano tutti assolutamente identici.
>
Ci avevo provato (veramente senza l'opzione -e).
Comunque il man echo dice:
"echo scrive ogni stringa data nello standard output, con
uno spazio tra l'una e l'altra e va a capo dopo l'ultima
(stampando un newline)."
Magari il mio dispositivo vuole anche un \r o un EOF.
Stassera riprovo con "echo -e ..."
grazie, andrea
rez
>rez wrote:
>>On Tue, 17 Apr 2001 14:37:55 +0200, Andrea Celli wrote:
>>>Crogiolandomi nella mia beata ignoranza, sono stato sempre
>>>convinto che i due comandi:
>>>$ echo qualcosa > pippo
>>>$ echo qualcosa | cat > pippo
>>>producessero esattamente lo stesso risultato.
>............
>>Cmq con echo non c'entrera` la storia di escape? Prova con -e.
>>D'altra parte [visto che a Daniele va] da certi, echo e` built-in.
>Posso provarci.
>Sarebbe come se echo inviasse "qualcosa" seguito da una newline
>(cosi` dice il man) e che il cat ci aggiunga un EOF o qualcosa
>di simile che dovrei aggiungere io a mano.
>O ti ho capito male?
Si` e no.. bisogna vedere se si invia un file di testo o binario.
Voglio dire che una cosa e` l'input da tastiera che davi per echo e
un'altra e` il file con cat. Questo appunto per l'EOF.
EOF ce lo dovrebbero mettere i programmi, non essenso un carattere
ASCII. Dovrebbero trovarlo da qualche parte ed in qualche modo, che
non mi e` ancora chiaro: e` il segnale perche' terminino.
Guarda, ho fatto con vi il file abc che contiene questa sola riga:
a b c
e basta, cioe` NOn ho dato invio e ho salvato. Vi mi ha messo \n.
Allora l'ho editato in esa con mc e ho cambiato 0x0a-->0x61. Bene,
ovviamente cat trova da qualche parte l'EOF e termina.
Anche il comando r di ex lo trova, l'EOF, guarda: (:r abc)
a b ca
Il file e`: (:r!cat abc|hexdump)
0000000 2061 2062 6163
0000006
Cavoli, tutti registri a parola:-(
Vediamo cosi`: (:r!cat abc|hexdump -b)
0000000 141 040 142 040 143 141
0000006
Ok, ho ucciso little big endian;-)
>La cosa strana e` che i due comandi precedenti mi generano
>due file pippo esattamente identici anche leggendoli
>in esadecimale.
>Con hexedit dovrei vedere anche i caratteri di controllo.
>O sbaglio?
Direi anch'io assolutamente si`, ci mancherebbe. Anche da me vengono
tutti uguali e tutti finiscono con new line che io non metto di certo:
echo 'a b c' > abc_echo
echo 'a b c' | cat > abc_echo-cat
vi abc_vi
cat abc_vi > abc_vi-cat
Sono tutti identici tra loro ed uguali a quello che ho messo piu` su.
rez
Invece penso piuttosto alla teoria di Daniele.. prova ad immetterlo
controllando il flusso con dd:
dd if=pippo of=/dev/ttyS0
che ha di default bs=512, e poi allora:
dd if=pippo of=/dev/ttyS0 bs=1
Io purtroppo ho le mani legate ed invece mi affascina. Non ho nessuna
seriale, che le ho disabilitate da bios tutte due. Ho solo il modem
interno che e` ttyS1, ma non ci capisco una mazza coi modem.
Andrea Celli
>
> On Wed, 18 Apr 2001 10:56:18 +0200, Andrea Celli wrote:
> >rez wrote:
> >>On Tue, 17 Apr 2001 14:37:55 +0200, Andrea Celli wrote:
>
> >>>Crogiolandomi nella mia beata ignoranza, sono stato sempre
> >>>convinto che i due comandi:
> >>>$ echo qualcosa > pippo
> >>>$ echo qualcosa | cat > pippo
> >>>producessero esattamente lo stesso risultato.
> >............
>
> >>Cmq con echo non c'entrera` la storia di escape? Prova con -e.
> >>D'altra parte [visto che a Daniele va] da certi, echo e` built-in.
>
> >Posso provarci.
...............
> Si` e no.. bisogna vedere se si invia un file di testo o binario.
Il "qualcosa" che devo inviare sulla seriale e` una banalissima
stringa di comando: DMP
Ieri sera ho fatto tutte le possibili prove con echo -e:
echo -e DMP\n
echo -e "DMP\n\r"
echo -e `DMP\f`
.........
e possibili combinazioni di virgolette e caratteri di controllo.
L'unica che ha funzionato e` stata:
echo -e DMP\nDMP\n #repetita juvant :-)
Mi sono detto: si perde qualcosa all'inizio e gli serve un
ritorno a capo da cui partire "pulito".
Ho provato:
echo -e \nDMP\n
echo -e pippo\nDMP\n
NON funzionano!
Potrebbe essere legato alla lentezza della porta sul dispositivo
(9600baud)?
Ma anche se fosse, perche' cat non risente del problema?
ciao, Andrea
PS. non so se possa servire, ma anche perl si comporta come echo.
Se apro la seriale in lettura riesco a leggere tutto,
se la apro in scrittura un
open (comando, ">/dev/ttyS0")||die "apertura device $!\n";
print comando "DMP\n"||die "stampa DMI: $!\n";
close(comando) || die "chiusura device $!\n";
non funziona. Devo metterci un `echo DMP|cat >/dev/ttyS0`
Non ho ancora provato a ripetere la stringa in perl.
Fabio Bonelli
>>(cosi` dice il man) e che il cat ci aggiunga un EOF o qualcosa
>>di simile che dovrei aggiungere io a mano.
>>O ti ho capito male?
> Si` e no.. bisogna vedere se si invia un file di testo o binario.
> Voglio dire che una cosa e` l'input da tastiera che davi per echo e
> un'altra e` il file con cat. Questo appunto per l'EOF.
E' la stessa cosa, sia testo che binario.
> EOF ce lo dovrebbero mettere i programmi, non essenso un carattere
> ASCII. Dovrebbero trovarlo da qualche parte ed in qualche modo, che
> non mi e` ancora chiaro: e` il segnale perche' terminino.
Attenzione a non confondere due cose diverse:
- la costante EOF definita in stdio.h (di solito vale -1)
- il carattere EOF, roba dei terminali.
La prima e' quella che interessa a noi. Quando fai:
$ cat file
cat(1) fa una cosa di questo tipo:
while ( (ch = fgetc(stream)) != EOF)
putchar(ch);
Ora, a forza di leggere dal file prima o poi si raggiunge la fine,
fgetc se ne accorge e fa un "return EOF", _non_ perche' legga qualcosa dal
file che di puo' definire "l'end of file", ma perche' non c'e' piu' file
da leggere.
Il ciclo esce e lo pseudo-cat termina.
Altro modo per terminare cat? La "seconda cosa diversa" :-) :
Mandiamogli il carattere EOF. Ma di per se il carattere EOF non esiste,
e' un invenzione, e solitamente si "crea" con CTRL-D.
Premendo ^D il driver della tty, lo riconosce come carattere EOF, si
bulla con gli amici e manda un SIGINT al processo in foreground, cat.
>>Con hexedit dovrei vedere anche i caratteri di controllo.
>>O sbaglio?
> Direi anch'io assolutamente si`, ci mancherebbe. Anche da me vengono
> tutti uguali e tutti finiscono con new line che io non metto di certo:
echo(1) stampa un newline per default, mentre cat non ci pensa neanche.
E' vim che non dovrebbe metterne senza chiedere (un bug?).
--
Fabio Bonelli fabio161616(at)libero.it blackmagic(at)penguinpowered.com
C isn't that hard: void (*(*f[])())() defines f as an array of
unspecified size, of pointers to functions that return pointers to
functions that return void.
Fabio Bonelli
> L'unica che ha funzionato e` stata:
> echo -e DMP\nDMP\n #repetita juvant :-)
Senza virgolette? Cosi' i \n non sono protetti e l'output e' DMPnDMPn\n,
l'ultimo \n lo mette echo.
> echo -e \nDMP\n
> echo -e pippo\nDMP\n
Occhio ancora alle virgolette, comunque.
> Potrebbe essere legato alla lentezza della porta sul dispositivo
> (9600baud)?
> Ma anche se fosse, perche' cat non risente del problema?
Con cat dovrebbe essere la stessa identica cosa. Che sia qualcosa legato
al buffering?
Suggerisco per precauzione un buon esorcismo. :-)
--
Fabio Bonelli fabio161616(at)libero.it blackmagic(at)penguinpowered.com
Sword fighting is kinda like making love. It's not
always what you do, but what you say. -- Captain Smirk
Fabio Laghi
news:3ADF027D...@iac.rm.cnr.it...
> rez wrote:
> >
> > On Wed, 18 Apr 2001 10:56:18 +0200, Andrea Celli wrote:
> > >rez wrote:
> > >>On Tue, 17 Apr 2001 14:37:55 +0200, Andrea Celli wrote:
> >
> Potrebbe essere legato alla lentezza della porta sul dispositivo
> (9600baud)?
> Ma anche se fosse, perche' cat non risente del problema?
>
Forse serve un datascope sulla seriale per vedere effettivamente i dati
uscenti.
Hai provato a metterti in ascolto sulla seriale per vedere i dati che
escono .
ciao.
--
Fabio
cinqua...@libero.it
rez
>rez <r...@tiscalinet.it> wrote:
>>>(cosi` dice il man) e che il cat ci aggiunga un EOF o qualcosa
>>>di simile che dovrei aggiungere io a mano.
>>>O ti ho capito male?
>>Si` e no.. bisogna vedere se si invia un file di testo o binario.
>>Voglio dire che una cosa e` l'input da tastiera che davi per echo e
>>un'altra e` il file con cat. Questo appunto per l'EOF.
>E' la stessa cosa, sia testo che binario.
Ma nei file binari un byte potrebbe valere -1, per questo motivo non
si deve usare feof?
[...]
>Ora, a forza di leggere dal file prima o poi si raggiunge la fine,
>fgetc se ne accorge e fa un "return EOF", _non_ perche' legga qualcosa dal
>file che si puo' definire "l'end of file", ma perche' non c'e' piu' file
>da leggere.
Tutto ok, ma per me il punto e` sempre e solo proprio questo: come fa
ad accorgersi che il file e` finito? Pesca l'EOF dal fs?
>Altro modo per terminare cat? La "seconda cosa diversa" :-) :
>Mandiamogli il carattere EOF. Ma di per se il carattere EOF non esiste,
>e' un invenzione, e solitamente si "crea" con CTRL-D.
>Premendo ^D il driver della tty, lo riconosce come carattere EOF, si
>bulla con gli amici e manda un SIGINT al processo in foreground, cat.
Gia`, ^D=EOT: fine del testo. Infatti se faccio girare:
main()
{
int c;
while((c=getchar())!=EOF)
putchar;
}
esce per ^C e ^D.
Pero` se poi nel sorgente cambio EOF con (ad es.) 0x0a, allora esce
se invio (=\n) e se do ^C, mentre mi da` l'ascii 0x0ff immettendo ^D.
D'altra parte se faccio invece girare questo:
#include <stdio.h>
main()
{
int c;
c=EOF;
putchar (c);
}
mi da` "y dieresi" = 0x0ff = -1. Dunque (per tutti i programmi in
questa macchina?) EOF e` la costante -1 = 0x0ff.
>>>Con hexedit dovrei vedere anche i caratteri di controllo.
>>>O sbaglio?
>>Direi anch'io assolutamente si`, ci mancherebbe. Anche da me vengono
>>tutti uguali e tutti finiscono con new line che io non metto di certo:
>echo(1) stampa un newline per default, mentre cat non ci pensa neanche.
>E' vim che non dovrebbe metterne senza chiedere (un bug?).
Da me ho messo Elvis. Dev'essere come dici tu un bug, visto che Mcedit
non lo mette e neanche Ae.
[ERESIA]
Pensavo che gli editor lo mettessero come edit.exe (ma non notepad.exe)
[/ERESIA]
Forse e` una versione vecchia, vediamo:
elvis 2.1_4
Copyright (c) 1995-1999 by Steve Kirkendall
Eresia doppia!! Mette anche \r, che faccio? Forse e` una versione
per winbug? Impossibile perche' era nel cdrom della Debian. :-(((
Bohh, disastro! Lo tolgo? E bellissimo, per il resto:-((
NicoKid
Mi intrometto :)
Per caso sai come fare per vedere anche i caratteri non stampabili che
arrivano alla seriale ?
Grazie, Nicola.
rez
>Il "qualcosa" che devo inviare sulla seriale e` una banalissima
>stringa di comando: DMP
Cos'e` DMP, roba di modem?
>Ieri sera ho fatto tutte le possibili prove con echo -e:
Senti, il resto del thread non lo seguo: non so niente sulle seriali.
Pero` volevo dirti: hai provato ad inviare anche con cat da tastiera,
anziche' da file?
D'altra parte con: echo DMP | cat > /dev/ttyS0, possono succedere cose
strane con la pipe.. penso diverse da macchina a macchina. La shell
crea una pipe, forka e redirige lo stdout sull'ingresso della pipe,
forka di nuovo e redirige lo stdin sull'uscita della pipe e lo stdout
su ttyS0: a questo punto puo` o no esserci gia` DMP, dipende dai tempi
del primo fork che ha fatto exec su echo. Se non c'e`, invia prima
niente e poi DMP.
Fabio Laghi
news:qfhqb9...@doppioproc.localdomain...
> Sorseggiando il suo prosecco Fabio Laghi, si rivolse al NG dicendo...
Era Sangiovese -:)
> Per caso sai come fare per vedere anche i caratteri non stampabili che
> arrivano alla seriale ?
Il metodo piu' semplice , ma piu' costoso , e' un DataScope Hw.
Un altro e' una vecchia stampante con test in esadecimale di quello che
gli arriva.
Infine prova a cercare , se esiste , un software per linus che abbia la
funzione di datascope .
ciao.
--
Fabio
cinqua...@libero.it
roberto
<cinqua...@libero.it> wrote:
>"NicoKid" <NOSPAM...@tin.it> ha scritto nel messaggio
>news:qfhqb9...@doppioproc.localdomain...
>> Sorseggiando il suo prosecco Fabio Laghi, si rivolse al NG dicendo...
>
>Era Sangiovese -:)
>
>> Per caso sai come fare per vedere anche i caratteri non stampabili che
>> arrivano alla seriale ?
>
>Il metodo piu' semplice , ma piu' costoso , e' un DataScope Hw.
Oppure un datascope software, basta avere un secondo pc da collegare.
Avevo trovato un serial monitor per dos, se interessa davvero cerco il
link (si chiama DLM data line monitor, ed e' di un certo dunfield
development system, canadese)
Mi sembra fosse Shareware, l'ho provato una volta e funzionicchiava
abbastanza bene.
>Un altro e' una vecchia stampante con test in esadecimale di quello che
>gli arriva.
Giusto, ma non e' cosi' facile trovarle.
>Infine prova a cercare , se esiste , un software per linus che abbia la
>funzione di datascope .
hexdump </dev/ttyS1
--
|Save our planet!
Ciao |Save wildlife;
roberto |For your E-MAIL use only recycled Bytes !!
|roberto poggi rpo...@softhome.net
NicoKid
> On Mon, 23 Apr 2001 06:39:00 GMT, "Fabio Laghi"
> <cinqua...@libero.it> wrote:
>
> >"NicoKid" <NOSPAM...@tin.it> ha scritto nel messaggio
> >news:qfhqb9...@doppioproc.localdomain...
> >> Sorseggiando il suo prosecco Fabio Laghi, si rivolse al NG dicendo...
> >
> >Era Sangiovese -:)
L'importante e' che non sia acqua....
> >> Per caso sai come fare per vedere anche i caratteri non stampabili che
> >> arrivano alla seriale ?
> >
> >Il metodo piu' semplice , ma piu' costoso , e' un DataScope Hw.
> Oppure un datascope software, basta avere un secondo pc da collegare.
> Avevo trovato un serial monitor per dos, se interessa davvero cerco il
> link (si chiama DLM data line monitor, ed e' di un certo dunfield
> development system, canadese)
> Mi sembra fosse Shareware, l'ho provato una volta e funzionicchiava
> abbastanza bene.
Meglio di hexdump?
> >Un altro e' una vecchia stampante con test in esadecimale di quello che
> >gli arriva.
> Giusto, ma non e' cosi' facile trovarle.
> >Infine prova a cercare , se esiste , un software per linus che abbia la
> >funzione di datascope .
> hexdump </dev/ttyS1
Ma sto' hexdump vede tutto? Nel senso non e' che si limiti a convertire in
hex quello che arriva in ascii perdendosi la roba interessante?
Andrea Celli
>
> >
> >> Per caso sai come fare per vedere anche i caratteri non stampabili che
> >> arrivano alla seriale ?
> >
> >Il metodo piu' semplice , ma piu' costoso , e' un DataScope Hw.
> Oppure un datascope software, basta avere un secondo pc da collegare.
> >Infine prova a cercare , se esiste , un software per linus che abbia la
> >funzione di datascope .
> hexdump </dev/ttyS1
In pratica cosa dovrei fare?
Io non ho mai visto, neanche in foto, un datascope. :-(
Se ho ben capito si tratterebbe di avere un secondo PC Linux,
attaccarlo al primo tramite seriale, lanciare
hexdump </dev/ttySx dal secondo
e echo qualcosa > /dev/ttySy dal primo
e vedere cosa "raccoglie" hexdump.
Giusto?
Vedo se riesco a procurarmi il tutto e fare una prova.
grazie, Andrea
Fabio Bonelli
>>E' la stessa cosa, sia testo che binario.
> Ma nei file binari un byte potrebbe valere -1, per questo motivo non
> si deve usare feof?
No. feof() si usa sugli stream per capire se una delle funzioni di
lettura dallo stream ha ritornato EOF perche' e' finito il file o
perche' c'e' stato un errore.
Le varie fgetc(), getc(), fgets(), ecc... ritornano EOF per un errore o
per la fine del file.
> [...]
>>Ora, a forza di leggere dal file prima o poi si raggiunge la fine,
>>fgetc se ne accorge e fa un "return EOF", _non_ perche' legga qualcosa dal
>>file che si puo' definire "l'end of file", ma perche' non c'e' piu' file
>>da leggere.
> Tutto ok, ma per me il punto e` sempre e solo proprio questo: come fa
> ad accorgersi che il file e` finito? Pesca l'EOF dal fs?
Tutte queste funzioni di libreria alla fin fine faranno una read(2) che
e' nel kernel.
Il kernel ha un elenco dei file aperti per ogni processo e a ogni
descrittore e' associato anche l'offset corrente del file (che puoi
modificare con lseek(2)) e l'inode che lo descrive, in cui c'e' la
lunghezza effettiva del file.
Quindi se siamo in una situazione in cui l'offset corrente e', diciamo,
4 e la lunghezza del file e' 4 e fgetc() chiama
read( fd, buf, sizeof(char) ), read stessa si accorge che e' alla fine e
non c'e' verso di leggere roba da quel descrittore, ritorna 0 e fgetc()
ritorna EOF a sua volta.
>>Altro modo per terminare cat? La "seconda cosa diversa" :-) :
>>Mandiamogli il carattere EOF. Ma di per se il carattere EOF non esiste,
>>e' un invenzione, e solitamente si "crea" con CTRL-D.
>>Premendo ^D il driver della tty, lo riconosce come carattere EOF, si
>>bulla con gli amici e manda un SIGINT al processo in foreground, cat.
Scusa, qui mi sono confuso io. :-) Tutto giusto, eccetto il fatto che il
driver non manda nessun segnale al processo (quello e' ^C), ma flusha
immediatamente tutti i caratteri al processo col risultato pratico di
far ritornare 0 a read(2) e quindi EOF a getc().
> Gia`, ^D=EOT: fine del testo. Infatti se faccio girare:
> main()
> {
> int c;
> while((c=getchar())!=EOF)
> putchar;
> }
> esce per ^C e ^D.
Ok, esce per ^C per il driver che manda SIGINT, ed esce per ^D a causa
del flush che rende false la condizione del while, in quanto getchar()
ritorna EOF.
> Pero` se poi nel sorgente cambio EOF con (ad es.) 0x0a, allora esce
> se invio (=\n) e se do ^C, mentre mi da` l'ascii 0x0ff immettendo ^D.
Cosa c'e' di strano? Esce con invio proprio per la condizione nel while,
per ^C per il SIGINT e scrive il contenuto di `c' (che e' EOF, aka -1,
aka ascii 255, aka ascii 0x0ff). `c' e' EOF a causa del flush.
> D'altra parte se faccio invece girare questo:
> #include <stdio.h>
> main()
> {
> int c;
> c=EOF;
> putchar (c);
> }
> mi da` "y dieresi" = 0x0ff = -1. Dunque (per tutti i programmi in
> questa macchina?) EOF e` la costante -1 = 0x0ff.
Ah ecco. :-) Si', esatto, e' definita in stdio.h.
>>echo(1) stampa un newline per default, mentre cat non ci pensa neanche.
>>E' vim che non dovrebbe metterne senza chiedere (un bug?).
[...]
> Da me ho messo Elvis. Dev'essere come dici tu un bug, visto che Mcedit
> non lo mette e neanche Ae.
A quanto pare anche vim qui da me lo fa.
> Eresia doppia!! Mette anche \r, che faccio? Forse e` una versione
> per winbug? Impossibile perche' era nel cdrom della Debian. :-(((
> Bohh, disastro! Lo tolgo? E bellissimo, per il resto:-((
E perche' mai? Per cosi' poco? E i sorgenti che ci stanno a fare, per
bellezza? :-)
--
Fabio Bonelli fabio161616(at)libero.it blackmagic(at)penguinpowered.com
"Software is like sex: It's better when it's free."
-- Linus Torvalds, from FSF T-shirt
roberto
[...]
>> link (si chiama DLM data line monitor, ed e' di un certo dunfield
>> development system, canadese)
>> Mi sembra fosse Shareware, l'ho provato una volta e funzionicchiava
>> abbastanza bene.
>
>Meglio di hexdump?
Funziona con tutte e due le seriali contemporaneamente, bisogna fare un
cavetto a Y, un capo alla macchina di controllo, su tutte due le
seriali, e gli altri due ai due apparecchi da tenere sotto controllo.
A quel punto, sul video ( e su file) hai le due linee dati, con i
caratteri che circolano, e dalla posizione sai anche la sequenza con cui
il protocollo funziona.
[...]
>Ma sto' hexdump vede tutto? Nel senso non e' che si limiti a convertire in
>hex quello che arriva in ascii perdendosi la roba interessante?
E secondo te quale sarebbe, la roba interessante?
I segnali di controllo della seriale? quelli non li puoi vedere altro
che con un datascope.
I caratteri di controllo della seriale(XON-XOFF)? quelli non li vedi con
l'exdump settato sulla stessa seriale che riceve, devi inserire una
macchina con funzioni di datascope, appunto.
roberto
wrote:
[...]
>In pratica cosa dovrei fare?
>Io non ho mai visto, neanche in foto, un datascope. :-(
connessione (seriale, in questo caso) e registra cosa sta arrivando da
un lato, lo ripete dall'altro, e vede cosa arriva dall'altro, e cosi'
via.
[pc]<-->[datascope]<-->[modem]
RX --+---------------- TX
+---RX(1)
TX --------------+---- RX
RX(2)---+
GND --+---------------- GND
+---GND(1)-GND(2)
Si puo' fare, come dicevo, succhiando i dati tramite le due seriali di
un pc standard, e un apposito software.
Colleghi l'uscita del pc all'RX della com1 del datascope.
Colleghi l'uscita del modem all'RX della com2 del datascope.
Lanci il programma monitor, e a video ( e su file) trovi i caratteri che
passano, separati per interfaccia, e in ordine temporale.
Il gioco con hexdump su una delle due seriali, ha dei limiti, sia per
quello che riguarda eventuali caratteri di protocollo, sia per quanto
riguarda la non gestione temporale del protocollo tra DUE
apparecchiature.
NicoKid
> On Mon, 23 Apr 2001 22:50:00 GMT, NicoKid <NOSPAM...@tin.it> wrote:
cut...............
>
> >Ma sto' hexdump vede tutto? Nel senso non e' che si limiti a convertire
> >in hex quello che arriva in ascii perdendosi la roba interessante?
> E secondo te quale sarebbe, la roba interessante?
> I segnali di controllo della seriale? quelli non li puoi vedere altro
> che con un datascope.
> I caratteri di controllo della seriale(XON-XOFF)? quelli non li vedi con
> l'exdump settato sulla stessa seriale che riceve, devi inserire una
> macchina con funzioni di datascope, appunto.
>
In pratica io voglio vedere se viene fuori questa roba sul pc collegato
all'altra seriale:
/* variabili e costanti */
#define STX 0x02
typedef unsigned char uchar;
/* definizione di buffer */
uchar buffer[10];
/* invio dati */
buffer[0]=STX; /* Trasmetti STX */
write(modem,buffer,1);
Altrimenti vuol dire che il baco sta' prima di questa roba.
Fabio Laghi
news:3ae41725.21601025@mail...
> On Mon, 23 Apr 2001 06:39:00 GMT, "Fabio Laghi"
> <cinqua...@libero.it> wrote:
>
> Oppure un datascope software, basta avere un secondo pc da collegare.
Si e' corretto . Comunque con emulatori sw ho sempre avuto qualche
problema .
E se devi controllare il flusso dei dati in tutti e due i sensi credo
che l'unico sia quello Hw.
ciao.
--
Fabio
cinqua...@libero.it
Fabio Laghi
news:3AE55088...@iac.rm.cnr.it...
> roberto wrote:
>
> Se ho ben capito si tratterebbe di avere un secondo PC Linux,
> attaccarlo al primo tramite seriale, lanciare
> hexdump </dev/ttySx dal secondo
> e echo qualcosa > /dev/ttySy dal primo
> e vedere cosa "raccoglie" hexdump.
> Giusto?
Forse potresti provare anche con lo stesso Pc .
L'importante e' avere 2 seriali disponibili .
ciao
--
Fabio
cinqua...@libero.it
Andrea Celli
>..........
> Il gioco con hexdump su una delle due seriali, ha dei limiti, sia per
> quello che riguarda eventuali caratteri di protocollo, sia per quanto
> riguarda la non gestione temporale del protocollo tra DUE
> apparecchiature.
>
Mmmmh.
Quanto costa un data-scope?
C'e` la possibilita` di trovarli a noleggio?
Credo che dovro` accontentarmi di quello che ricavo da
un tentativo software.
ciao, andrea
roberto
>Sorseggiando il suo prosecco roberto, si rivolse al NG dicendo...
Oh, finalmente fai passare la sete anche a me.:-)
>In pratica io voglio vedere se viene fuori questa roba sul pc collegato
>all'altra seriale:
[...]
>buffer[0]=STX; /* Trasmetti STX */
>write(modem,buffer,1);
>
>Altrimenti vuol dire che il baco sta' prima di questa roba.
Allora, se non hai problemi di handshake hardware-software, anche con
l'hexdump lo devi vedere.
roberto
<cinqua...@libero.it> wrote:
[...]
>Si e' corretto . Comunque con emulatori sw ho sempre avuto qualche
>problema .
>E se devi controllare il flusso dei dati in tutti e due i sensi credo
>che l'unico sia quello Hw.
superobsoleto come uso io, con un programmino ad hoc.
L'importante e' che NON faccia da bridge, ma solo da sniffer, e che sia
abbasdtanza veloce con le seriali.
A quel punto, e' solo questione di avere un ottimo polling sulle seriali
per vedere il flusso correttamente incolonnato come sviluppo nel tempo.
roberto
wrote:
[...]
>> apparecchiature.
>>
>
>Mmmmh.
>Quanto costa un data-scope?
>C'e` la possibilita` di trovarli a noleggio?
Ti consiglio di provare a cercare DLM[*], e sfruttare un qualsiasi pc
con due seriali e un dos dal 3.3 in avanti, con un cavetto che ti puoi
fare anche da solo (se tu fossi dalle mie parti, potrei prestarti il
tutto)
Con quello riesci a tenere sotto controllo la comunicazione.
Pagando una manciata di dollarucci[**], puoi avere anche la versione che
registra su file il traffico.
[*] Se non lo trovi al volo, te lo posso inviare in mail, sono poche
decine di k, e la versione che non salva su file e' liberamente usabile,
da quel che so, almeno come test.
[**]Non a me, ai canadesi che hanno programmato il monitor.
Andrea Celli
>........
> Ti consiglio di provare a cercare DLM[*], e sfruttare un qualsiasi pc
> con due seriali e un dos dal 3.3 in avanti, con un cavetto che ti puoi
cos'e` un semplice cavo seriale-seriale che si trova anche in un
negozio o ha qualche "scambio" particolare o qualche dispositivo
in mezzo?
Forse, pero` dovrei trovare il modo di connetterlo con quello
descritto in:
http://www.geocities.com/SiliconValley/Haven/5371/indexe.html
che poi attacco alla seriale.
Quindi, puoi dirmi a che poli della seriale devo connettere i
Tx, Rx e GND del connettore jack ?
ciao e grazie, andrea
roberto
wrote:
>roberto wrote:
>>........
>> Ti consiglio di provare a cercare DLM[*], e sfruttare un qualsiasi pc
>> con due seriali e un dos dal 3.3 in avanti, con un cavetto che ti puoi
>> fare anche da solo .....
>
>cos'e` un semplice cavo seriale-seriale che si trova anche in un
>negozio o ha qualche "scambio" particolare o qualche dispositivo
>in mezzo?
Se cerchi, in questo stesso thread, c'e' un mio post con la mappa del
cavo, comunque, non serve nessun dispositivo, solo un intreccio di fili:
[pc1]<-->[datascope]<-->[altro]
RX --+---------------- TX
+---RX(1)
TX --------------+---- RX
RX(2)---+
GND --+---------------- GND
+---GND(1)-GND(2)
In pratica servono 4 connettori: ai due estremi, qui sopra ci sono le
due apparecchiature da tenere sotto controllo.
In mezzo, si collegano i due fili dati (rx e tx) ognuno all'RX delle due
porte com del pc che fa da monitor, e la massa in comune.
>
>Forse, pero` dovrei trovare il modo di connetterlo con quello
>descritto in:
>http://www.geocities.com/SiliconValley/Haven/5371/indexe.html
>che poi attacco alla seriale.
Adesso ci vado a vedere...
Secondo me, non serve a nulla,a a meno che tu non abbia proprio quel
misuratore.
ti faccio l'elenco dei piedini da collegare:
4 connettori 9 pin:
connettore 1) uscita del primo pc in esame
connettore 2) uscita del secondo pc in esame (o altra apparecchiatura,
ma la piedinatura te la indico come fosse un altro pc.
connettore 3) com1 del pc-monitor
connettore 4) com2 del pc-monitor
Tutti i pin 5 collegati tra loro (massa segnale)
Pin 3 connettore 1 al pin 2 connettore 3 e al pin 2 connettore 2
Pin 2 connettore 1 al pin 2 connettore 4 e al pin 3 connettore 2
eventuali altri segnali da conn.1 a conn.2 restano fuori da questa
storia (dsr, dtr, insomma, i pin per l'handshake hardware) e vanno
lasciati collegati come sarebbero se non inserissi in mezzo il monitor.
Anzi, per tagliare la testa al toro:
Prendi il cavo che gia' funziona, apri uno dei due connettori, e
colleghi tre fili a: pin di massa (5 se a 9 pin, 7 se a 25) e i pin 2 e
3, senza interromprei collegamenti precedenti.
La massa la porti ad entrambi i connettori del pc-monitor, gli altri
due, uno al pin 2 della COM1, uno al pin 2 della COM2.
NicoKid
> On Thu, 26 Apr 2001 01:22:20 GMT, NicoKid <NOSPAM...@tin.it> wrote:
>
> >Sorseggiando il suo prosecco roberto, si rivolse al NG dicendo...
> Oh, finalmente fai passare la sete anche a me.:-)
cin cin :)
> >In pratica io voglio vedere se viene fuori questa roba sul pc collegato
> >all'altra seriale:
> [...]
> >buffer[0]=STX; /* Trasmetti STX */
> >write(modem,buffer,1);
> >
> >Altrimenti vuol dire che il baco sta' prima di questa roba.
> Allora, se non hai problemi di handshake hardware-software, anche con
> l'hexdump lo devi vedere.
Ok, allora cerco il bachetto nel programma :)
NicoKid
> roberto wrote:
> >........
> > Ti consiglio di provare a cercare DLM[*], e sfruttare un qualsiasi pc
> > con due seriali e un dos dal 3.3 in avanti, con un cavetto che ti puoi
> > fare anche da solo .....
>
> cos'e` un semplice cavo seriale-seriale che si trova anche in un
> negozio o ha qualche "scambio" particolare o qualche dispositivo
> in mezzo?
Scusate, non e' che basta quell'affare con le lucette che si accendo e che
si attacca alla seriale alla modica cifra di 40-50 mila lire?
P.S. (io ne ho uno e solo che si accendono le luci ... ma non capisco
a cosa servono ;-))
rez
>rez <r...@tiscalinet.it> wrote:
>>>echo(1) stampa un newline per default, mentre cat non ci pensa neanche.
>>>E' vim che non dovrebbe metterne senza chiedere (un bug?).
>[...]
>>Da me ho messo Elvis. Dev'essere come dici tu un bug, visto che Mcedit
>>non lo mette e neanche Ae.
>A quanto pare anche vim qui da me lo fa.
Ah be', meglio cosi` perche' stavo gia` pensando di passare a vim.
Dunque allora si vede che e` una precisa scelta.. e chissa` perche'.
THNX per la storia dell'EOF!
>>Bohh, disastro! Lo tolgo? E bellissimo, per il resto:-((
>E perche' mai? Per cosi' poco? E i sorgenti che ci stanno a fare, per
>bellezza? :-)
Si`, buona notte! Ne ho da magna' pagnotte prima di saper mettere le
mani sui sorgenti :-(
Andrea Celli
> >
> >Forse, pero` dovrei trovare il modo di connetterlo con quello
> >descritto in:
> >http://www.geocities.com/SiliconValley/Haven/5371/indexe.html
> >che poi attacco alla seriale.
> Adesso ci vado a vedere...
> Secondo me, non serve a nulla,a a meno che tu non abbia proprio quel
> misuratore.
In effetti, tutto il problema nasce dal fatto che voglio fare un
programmillo perl per leggere e gestoire i dati di quel misuratore
da Linux.
Quindi, tutto quello che mi interessa deve passare da quel connettore
un po' particolare, oltre che dalla seriale.
In realta` ho un connettore similare, prodotto dalla casa produttrice
del misuratore. Diciamo: quello ufficiale.
Io, quindi, devo assicurarmi che i messaggi escano giusti dalla
seriale e poi non vengano maltrattati da quel connettore.
Almeno, che il "maltrattamento" sia omogeneo con cat, echo e perl.
Adesso, cerchero` di mettere in pratica le tue indicazioni.
Anche se non sono molto esperto in elettrotecnica, mi sono
sembrate abbastanza chiare.
ciao e grazie, andrea
roberto
[cut]
>Scusate, non e' che basta quell'affare con le lucette che si accendo e che
>si attacca alla seriale alla modica cifra di 40-50 mila lire?
ci riesci ad analizzare il traffico, vedi solo se i segnali di controllo
dell'handshake hardware ci sono, e se c'e' passaggio di dati.
Ma non riuscirai mai a sapere COSA passa per la seriale.