I spotted the following code in src/tool_operate.c

         input.fd = infd;
         input.config = config;
         my_setopt(curl, CURLOPT_READDATA, &input);
         /* what call to read */
         if((outfile && !curlx_strequal("-", outfile)) ||
            !checkprefix("telnet:", this_url))
           my_setopt(curl, CURLOPT_READFUNCTION, tool_read_cb);

It seemed to me that if the 'if' condition were false, then READFUNCTION
would remain as the default (fread) but READDDATA pointing to an
incompatible struct instead of a FILE. This could not possibly work,
could it?

Further investigation in lib/telnet.c revealed a partial explanation: if
READFUNCTION is not set, then input is read from hard-coded file
descriptor 0 (i.e. stdin) and any setting of READDATA (aka INFILE) is
disregarded:

   if(data->set.is_fread_set) {
     poll_cnt = 1;
     interval_ms = 100; /* poll user-supplied read function */
   }
   else {
     pfd[1].fd = 0;
     pfd[1].events = POLLIN;
     poll_cnt = 2;
     interval_ms = 1 * 1000;
   }
   ...
       if(poll_cnt == 2) {
         if(pfd[1].revents & POLLIN) { /* read from stdin */
           nread = read(0, buf, BUFSIZE - 1);
         }
       }

I think this is a bug: the fd to use in this optimisation should be
obtained by calling fileno((FILE *)conn->fread_in) - subject to
portability considerations of course.

Going back to tool_operate.c, even allowing for what appears to be an
intended optimisation of using the OS to poll for input, the test is
checking whether or not an output file is set, which is surely irrelevant.

   curl telnet://localhost:80 -T in1 -o out < in2

sends in1 whereas

   curl telnet://localhost:80 -T in1 > out < in2

sends in2. I think this is another bug.

-- 
Colin
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html