Re: lynx-dev libreadline

[Klaus Weide]

On Sun, 12 Dec 1999, brian j pardy wrote:

> Yeah, I've still been planning on taking a look.  My home machine was
> having a lot of problems (motherboard going out), so I had been trying
> to do as little as possible on it.  Now that I bought a new box, I'm
> slowly building everything back up to spec and will very soon be able
> to get back to it.
> 
> Re-reading the posts from that thread, I think your (second) proposal
> is the one that I find most attractive.  

I'm not sure it's the better one; it's more flexible, but requires a
bit more typing.  Well for batch-like use, that should be ok.  Glad
to leave the decision to you (or others).

> Sorry to quote so much, but I
> think it's worth bringing back up, since the thread diverted off into
> a discussion of how the -cookies option is a misnomer.

Thanks for the synopsis. (but snipped now)

> > [...] The only thing I find ugly about it is
> > that "/dev/null" is an OS-specific convention.
> 
> Is there anything in Lynx to mimic output to /dev/null for non-UNIX?
> 
> I'd rather not do an if(!unix && writefile != /dev/null) writecookies; 

You don't really need to, just check for "/dev/null" (if we say that
that should have Unix-ish /dev/null meaning on other systems, too).
If the user prefers to use a non-Unix system's native equivalent -
like "NUL:" (or "NUL"?) for DOS, etc., and "NL:" for VMS - it should
*automatically* have the same effect, the system will take care of
it.

> sort of thing -- has anyone solved this problem before?

The is some VMS-specific stuff in some files in src/, grep for "nl:".
But again, if you stick with just opening the file for writing, write,
close, as it is now, then no special recognizing of those names should
be necessary.

Actually, what I'd like to see (and maybe one day implement, but not
now - please do so if you have the time) is a sefaer way for writing
files.  At least for "important" user files: .lynxrc and cookie files.
Lynx should creat a new temp file for writing, and only replace the
original file if writing was successful.  Somewhat like for bookmark
files when removing (but that code may be more complicated than
necessary).  In *that* case, recognizing OS-specific "NUL:" and "NL:"
names would probably be necessary.

   Klaus