On Sat, Nov 15, 2008 at 11:31:23AM +1100, Amos Shapira wrote:
I'm not near a computer to dig this but there should be a way to tell unix telnet to change the chars it sends for enter, read telnet(1).
Hope this helps.
--Amos
On 11/15/08, Frank M. Ramaekers FRamaekers@ailife.com wrote:
Okay, here are some things I found out.
- Linux telnet is sending a 0x0a for the enter key
- Windows putty program is sending a 0x0d for the enter key
- Windows telnet is sending a 0x0d0a for the enter key
- The device (don't ask) I'm working with doesn't like the Linux
telnet
I've tried coding the expect with 0x0d:
expect ">" send "m2" send "\x0d"
But, this doesn't seem to work.
I'm starting to run out of ideas.
Look at stty and the notion of cooked and raw tty devices. This is a key difference with Windows and Linux text.
Windows newline is a pair Unix/Linux is 0A LF ’\n’ (new line) and the line discipline expands the LF to the pair.
In you may need to set the tty to raw and then revisit your expect code. Also terminals can be wonkey. If you set $TERM to dumb you may find some sanity in your problem.
You can telnet to local host and run "od -xc" to see what you are sending. By tinkering with the stty setting you can toggle from cooked to half cooked to raw...
I think your problem is that your expectation is that the tty will reflect what you type and not cook it to something else.
In the early days of Unix the ability to have a newline not advance the roll permits overstrikes and simple line edits. LF need not imply a CR+LF pair. Thus this can be printed with seven bytes on the old yellow roll. a b c d
If you tinker with stty settings in scripts or programs save the initial settings so you can restore them. See stty's man page for stuff like: [-]icrnl translate carriage return to newline ... [-]igncr ignore carriage return ... [-]inlcr translate newline to carriage return ... etc.