Frage zur seriellen Schnittstelle

[mg-midget]

Hallo an alle,

hier steht ein alter (?) ISDN_TA von ZYXEL rum und ich wollte zur Bedienung desselben ein Shell-Skript basteln. Zwar weiß ich, daß man
mit tip(1) da schon sehr weit kommt (oder minicom, wie man will),
aber wenn man richtig abfragen und verzweigen will, wird das schnell
unhandlich.
Das konkrete Problem:

auf die Eingabe von ATI11 antwortet die Kiste mit dem aktuellen
Software-Stand (das klappt auch, von der Zeile in tip aus). Wenn ich
jetzt im Skript schreibe:

$ echo "ATI11" > /dev/cua

dann wird das wohl auch gehen, aber wo um Himmelswillen muss ich
die Antwort einsammeln, um sie auswerten zu können? Funktioniert
Umlenken in eine Variable? Vielleicht so:

$ set PATCHLEVEL="leer"
$ echo "ATI11" > /dev/cua > $PATCHLEVEL

oder geht das ganz anders?  Hat jemand sowas schon mal gemacht?
Kann mir nicht vorstellen, daß ich der Erste mit dem Problem bin ...


Grüße von Haasen

(offensichtlicher Progammier-Anfänger, sorry)

[mvsparky]

das kann leider nich funzen. versuchs mal mit

echo "ATI11" > /dev/cua | tail
oder
echo <`echo "ATI11" > /dev/cua`

also einer befehlsverkettung, wobei /dev/cua die ausgabe über stdout liefern muß.

gruß
yves

[mg-midget]

leider.

nichts davon hat funktioniert. ich habe dann einen schnittstellen-tester
dazwischen gehaengt (so ein ding mit rot/gruenen lumis fuer alle
leitungen) und da konnte ich sehen, dass daten aus dem TA in die
kiste laufen, aber auf der standardausgabe kamen die nicht an ...

wo versackt das, oder besser gefragt, warum versackt das bei tip(1)
nicht?

es muss doch moeglich sein, von /dev/term/b zu lesen.

schon verzweifelter


Hse

[mvsparky]

tip funzt nur interaktiv - leider. habe schon mit cu und echo in zig varianten rumprobiert. bisher noch keinen erfolg.

gruss
yves

[mg-midget]

hi,

ich hab gestern noch mal rumgebastelt, ohne jeden erfolg.

koennte es sein, dass ein neuer eintrag in der /etc/inittab weiterhilft?

hat jemand SOWAS schon mal gemacht?


Hse

[tg-it]

ich hab sowas zwar noch nicht gemacht. was jedoch helfen könnte wäre ein script in expect zu coden. damit kann man meines wissens gut auf solche terminalgesteuerten sachen reagieren.

gruß
thomas

[mvsparky]

koennte es sein, dass ein neuer eintrag in der /etc/inittab weiterhilft?

kann ich mir nich vorstellen. wenn ein getty sich den seriellen port geschnappt hat, bekommst du bei tip oder cu nur noch "device busy". cu is schon der richtige ansatz, denke ich. cu -l /dev/cua/b, z.b. ich kann es nur nich nachvollziehen, weil bei meinem sparcbook noch sol2.5.1 drauf is, und das modem /dev/cua/c nich so recht will. mach mal "man cu". stehen viele nach loesung riechende dinge drin.

gruss
yves