lynx-dev "terminal lacks the ability...", other -dump problems (was: Two questions from a user)

[Klaus Weide]

On Sun, 23 Apr 2000, Bob Izenberg wrote:

> Date: Thu, 20 Apr 2000 17:14:39 -0400
> Sender: address@hidden
> From: Sourav K. Mandal <address@hidden>
> To: address@hidden
> Subject: Two questions from a user
> 
> Dear lynx experts:

What OS are you using?  What version of lynx?

> I am invoking the following command from a PPP script:
> 
>   lynx -auth=${ID}:${PASSWD} -source -post_data ${URL}
> 
> where URL is of the form <http address>/<x-www-url-encoded post data>

You are misunderstanding what method POST means.  If the "post data"
is already encoded in the URL, then it isn't really "post" data, you
don't need -post_data since you need to make not a POST request but a
normal GET request.

If you really *do* have post data, then you need to feed it to lynx
on standard input.

> I am having two problems:
> 
> *  Since PPP has all file descriptors set to null, and I think that 
> is what is causing the following error message:
> 
>   Your terminal lacks the ability to clear the screen or position 
> the cursor.

I could reproduce this by invoking lynx from a crontab entry.  (In that
case file descriptors 0,1, and 2 are not "null" but pipes).  But only
with lynx compiled with the Slang library.

Your possible workarounds:
1) Use lynx compiled against ncurses, not slang.
2) Use slang, but compile without USE_KEYMAPS defined (needs obvious
   removal of '#define USE_KEYMAPS' in one or two places in LYCurses.h).
3) Actually (according to my experimentation) what matters is not the
   nature of the file descriptors, but just the $TERM environment
   variable.  So fake one in your script - use something like
      LYNX=vt100 lynx [your options here]
   (you need the env. variable, -term=vt100 is not good enough).

The problem is caused by this code in LYMain.c:

#if defined(USE_KEYMAPS) && defined(USE_SLANG)
    if (-1 == lynx_initialize_keymaps ())
        exit (-1);
#endif

This should not never be called if dump_output_immediately is true, it
makes no sense and just is unnecessary overhead.

> Lynx then quits.  When I run the script manually, everything works 
> fine.  How can disable lynx's efforts to manipulate the 
> (non-existant?) terminal?  Is lynx not the right program to use for 
> my purpose?  

Maybe not - depends what exactly you want.

> I tried wget, but I couldn't get it to "POST" anything 
> ...

Are you sure you need to POST?
How about some concrete examples (with real URLs)?

> *  As the reader can see, my auth info is on the command line.  
> While I am essentially the only user on my system, and the command 
> is only alive for a few moments, the given invocation is still 
> undesirable from a security standpoint.  

Indeed.

> I tried feeding the options 
> and post data through STDIN, but lynx hangs because it does not 
> receive an EOT (control-d) character.  

How can we reproduce this hang?  What exactly did you try?

> How can I a, say, "echo" an 
> EOT character?  Is there an ASCII code for it?  Should I feed the 
> post data into a temp file, then 'cat' it?


You could use your shell's "here-documents", something like

   #! /bin/sh
   /usr/local/bin/lynx -dump - http://localhost/rest-of-url <<__EOF__
   -auth=foo:bar
   __EOF__
   echo "lynx returned $?"

if you *don't* have post data.  Note the '-'.

If you *do* have post data, *and* also want to pass options in via
stdin, the following demonstrates how to do it:

   #! /bin/sh
   /usr/local/bin/lynx -dump - http://localhost/cgi-bin/addition <<__EOF__
   -auth=foo:bar
   -trace
   -post_data
   n1=1&counter=0&n2=2
   ---
   -source
   __EOF__
   echo "lynx returned $?"

(assuming that "n1=1&counter=0&n2=2" is your prepared post data.)
You should see the options both before and after the post data being
effective.

And of course, this should also use by putting the stuff between
     /usr/local/bin/lynx ... <<__EOF__
and
     __EOF__
in a file, say lynxinput.data, and then call lynx as
    /usr/local/bin/lynx -dump - < /path/to/lynxinput.data

> I do not subscribe to the list, so CCs to my personal address 
> (address@hidden) would be appreciated.  I apologize if these issues 
> have been addressed before, but I could not find a solution in the 
> archives.

Please subscribe to the list temporarily, or check the archives for
other responses that may not get cc'd.

   Klaus