On Thu, Sep 13, 2012 at 10:29 AM, Arnaud Rébillout <[email protected]> wrote: > Hi, > thanks a lot for your quick (and useful) answer Rich. > > >> There are lots of translation modes available at the terminal level, >> controllable with the stty command. There may be one to enable >> translation of carriage return characters (the enter key) to CR+LF >> combinations rather than just NL (LF). Otherwise, you could disable >> the translation entirely and just press enter followed by ^J at the >> end of each line... > > Sounds good, I never thought about it. I think changing such a low-level > behavior just for a specific telnet usage is a little bit overkill. But it > would do the job. > > >> Note that this only matters for interactive use, which is hopefully a >> rare thing. > > You're right, I forgot to tell that all of this happens in interactive usage > of telnet. It's just a convenient way of trying things with a SMTP server, > and understand a little bit how it works. > > >> Also, any SMTP server I've ever used accepts NL-only (with >> no CR) input, so for interactive use rather than script use (wherein >> the latter you would want to be fully robust against strict servers), >> it probably doesn't matter anyway... > > I'm experimenting with a gmail server at the moment. It works well until I > enter the DATA step. At this moment, the server fails to recognize the > termination line (ie. the line containing a single dot), and I get stuck > there with no way out. I figured out it's because of the missing CR > character. > > >> Another solution would be to use sed 's/$/^M/' | telnet ... (where ^M >> is a literal carriage return in the command line) so that telnet is >> reading from a pipe rather than a terminal, and sed is adding CR's for >> you... > > Yep ! That's great, exactly what I was looking for. I tried this solution, > and I had a little bit more trouble than expected, but it worked in the end. > > The first thing is that, for interactive use, you don't want sed to buffer > the data. And this feature is not implemented in busybox sed, so you need > another implementation of sed. > > The second thing is that there is this nasty piece of code in busybox > telnet.c source: > > else if (c == '\r') > outbuf[j++] = '\0'; /* CR -> CR NUL */ > > Hell ! For some reason, every CR has a NUL appended to it. So I had to > remove that, and then everything works fine. Any idea about the reason for > this stuff ? I read the comment above but it doesn't make sense to me...
I have no idea yet. Here is when it was added: commit 0e28e1fa0551487dd28a42f1dbeb5bf717817175 Author: Eric Andersen <[email protected]> Date: Fri Apr 26 07:20:47 2002 +0000 Forward port patch from Przemyslaw Czerpak <[email protected]>: 1. busybox-telnet dosn't inform server about the size of terminal screen. In the world of xterminals and frame buffers it's rather horrible to use fixed 80x24 region in upper-left corner of screen/window. 2. If client sends character 0x0d to the server then sends character 0x0a the server eat the second byte (0x0a) - it's described in telnet RFC. Client should send two bytes ( 0x0d + 0x0a or 0x0d + 0x00 ) insted of one 0x0d byte. 3. busybox telnet implementation wasn't 8bit clean (look at 0xff byte). I need it because I have to use binray transfer like rz/sz. So when I resloved the problem (2) I corrected this one two. This also contains a small cleanup patch from vodz, and some minor editing by me. + int i, j; byte * p = G.buf; + byte outbuf[4*DATABUFSIZE]; - for (i = len; i > 0; i--, p++) + for (i = len, j = 0; i > 0; i--, p++) { if (*p == 0x1d) { conescape(); return; } + outbuf[j++] = *p; if (*p == 0xff) - *p = 0x7f; + outbuf[j++] = 0xff; + else if (*p == 0x0d) + outbuf[j++] = 0x00; } - write(G.netfd, G.buf, len); + if (j > 0 ) + write(G.netfd, outbuf, j); _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
