hm das programm funzt etz(lag echt am CR), aber:
wenn ich eine bash/csh starte, kann es keine befehle ausführen.
kann es sein, dass die shells ebenfalls kein CR erkennen? und wenn ja wie kann ich das bei telnet umgehen???
keine Ahnung evtl musst du in umkehrrichtung auch 13,10 für newline senden damit telnet es erkennt. aber soweit musst du es in der klausur bestimmt nicht treiben 
jetzt hab ich noch eine weiterführende frage:
da telnet wohl immer 13,10 sendet, unix programme aber anscheinend nur 10 verarbeiten können, würd ich gern quaasi mein programm 2mal forken und einen sohn das exec machen lassen und den anderen zwischen socket und exec schalten, damit er evtl 13 rausfiltert.
is das sinnvoll so oder gibt es da vielleicht so spezielle methoden dafür (kompatibilität wird doch sonst auch immeer so gross geschrieben 
)
und muesste ich dann einen eigenen socket für die sohn-sohn kommunikation einrichtn, oder kann ich einfach vor dem forken die sohn std* geeignet miteinander verbinden (ich denk nicht, da der eine dann ja in tty schreibt und der andere davon liest…nich wa???)
übrigens danke mikey für die zahlreichen antworten :finger:
d’oh jez wirds langsam bös 
dabei darf man nie vergessen dass alles auf der VERMUTUNG basiert das telnet wirklich die 13,10 erzeugt und nicht etwa die socket Schnittstelle. Dann könntest Du einen Sohn zwischenschalten der aus dem Netzwerksocket liest und mit socketpair ein neues Paar unix domain sockets erzeugen (unix(7)) und den stdio dann auf einen dieser sockets umleiten. Aber wenn Du die 13 dann immer rausschmeisst veränderst du dadurch die übertragenen daten und das müssen ja nicht zwangsläufig strings sein…
Verwendet doch einfach netcat statt telnet… das Telnet macht mir eh zuviel Müll mit den Daten, so à la Terminal-Emulation etc. Eigentlich will ich doch nur eine einfache TCP-Verbindung, und keine farbige Ausgabe und Kontrollzeichenübersetzung usw…
ich kann ja einfach beim programmbefehl schauen ob ein 1310 dranhängt und davon ausgehen, dass dann immer eins kommt. das remote programm wird sich ja hoffentlich nicht ändern… :anx:
wenn der socket die ersetzung vornimmt, würde er ja dann jedes 10 durch 1310 ersetzen und so daten verfälschen… wäre wohl recht unpraktisch :motz:
funktionieren dann programme wie putty oda so auch nach diesem prinzip, also wartet zb im cip ein demon und putty kontaktet auf nem port und lässt ne shell ausführen.
sifrhirs@faui00h:~ > ps -A |grep sshd
364 ? 00:00:00 sshd
14814 ? 00:00:00 sshd
14822 ? 00:00:00 sshd
5471 ? 00:00:00 sshd
5479 ? 00:00:00 sshd
8350 ? 00:00:00 sshd
8358 ? 00:00:00 sshd
mit anderen Worten: ja