Re: lynx-dev libreadline

[brian j pardy]

On Sat, Dec 11, 1999, Klaus Weide wrote:
> On Sat, 11 Dec 1999, brian j pardy wrote:
> > > (Any chance you'll do something wrt cookie saving
> > > before 2.8.3 ? :))
> > 
> > What do you have in mind for cookie saving?  I have a bunch of saved
> > mail regarding cookie handling for dump/source (the thread between
> > yourself, Vlad, and Leonid, mainly) -- is this what you mean?
> 
> Yes; I had kinda thought you wanted to look into the saving-with-dump-
> and-source stuff.

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.  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.

[KW:]
> I've thought about it a bit more.  An additional
> -persistent_cookies_with_dump (or whatever name) flag just for
> (-dump/-source) is ugly.  There are already many flags that have
> only effect in one mode (noninteractive vs. interactive) and get
> ignored in the other, let's try to avoid adding another one here if
> we can provide something instead that's useful in both modes.
>
> So here's a somewhat different idea: A 'save_cookies' flag that
> tells lynx whther to *write* cookies to file or not.
> In interactive mode, default is
>  - ON if persistent cookies are enabled
>  - OFF if persistent cookies are disabled
> In noninteractive mode, default is
>  - OFF
>
[allow read-only cookie jar, filesharing, etc]
>
> I think now we should only distinguish (for purposes of this flag)
> between interactive and noninteractive, i.e. treat -dump and -source
> (even -mime_header) the same, as well as -dump implied by -get_data
> and -post_data.  I think now that the difference between -source and
> -dump that I brought up earlier isn't really worth bothering, it is
> theoretical only: I have never seen "Set-Cookie" used in an
> HTTP-EQUIV META tag in real pages.
> 
> I am not sure whether this should be command line flag, lynx.cfg option,
> or both, but probably both.
> 
> What do you think?  (And what do the consumers-of-cookies think?)
> 
> An extension of the above, for even more flexibility, would be to
> have a -cookie_write_file (or -cookie_save_file) separate from the
> normal -cookie_[read_]file.  By default they would be the same (for
> interactive use).  This would make the option proposed above
> unnecessary, because its behavior is included as
> -cookie_write_file=/dev/null (which would be the default for
> noninteractive invocation).  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; 
sort of thing -- has anyone solved this problem before?

-- 
OMNIVERSAL AWARENESS??  Oh, YEH!!  First you need 4 GALLONS of JELL-O
and a BIG WRENCH!! ... I think you drop th'WRENCH in the JELL-O as if
it was a FLAVOR, or an INGREDIENT ... ... or ... I ... um ... WHERE'S
the WASHING MACHINES?