Re: lynx-dev Command-line options syntax (was Command-line options and DOS)

[Doug Kaufman]

On Sun, 1 Aug 1999, Klaus Weide wrote:

> > when the initial boolean value is FALSE. When the initial value is
> > TRUE, this can give unexpected results (e.g. -show_cursor shows the
> > cursor only when -showcursor=off). 
> 
> I think you meant: 
>   (e.g. -show_cursor shows the cursor only when -show_cursor=on)
> 
> Or do I misunderstand?

I meant exactly what I said. You get the exact opposite result as
would be expected. -show_cursor is equivalent to -show_cursor=off or
to -show_cursor-. This starts with BOOLEAN TRUE and is toggled to
FALSE by -show_cursor. It seems that -show_cursor=on sets the value
to TRUE, leaving function unchaged. I think it was pointed out in
another thread a few days ago that the new option, -short_url, also
has boolean function opposite to what would be expected. I haven't
looked at that closely, however.
 
> > There is also a problem under
> > DOS, in that lynx is usually run from a batch file, with options
> > passes as "replaceable parameters" by the operating system. DOS uses
> > "=" as a non-configurable separator for options. Thus if the option
> > "-show_cursor=off" is given, the operating system passes to lynx
> > "-show_cursor off". Lynx dutifully tries to open the startfile "off".
> > 
> > I propose a few changes to improve this. Firstly, I added the value
> > ":" as a separator between the option and its value. This makes it
> > much easier under DOS. I didn't see where it would adversely impact
> > other systems. If it does, it can be ifdef'd to __DJGPP__. Changes to
> > lynx.man, lynx.hlp, and the lynx users guide are proposed. I deleted
> > the statement that white space can be substituted for "=" in the
> > command line options, since it doesn't always appear to be true (it
> > does work for -cfg).
> 
> That statement should still be true for all "=" except those that
> are part of the alternative forms for "-option+" and "-option-".
> In other words, it is still true that all those "=" signs that
> appear explicitly in the man page and UG and -help option listings
> can be replaced by spaces.
> 
> Actually, if DOS changes "=" to " " (in some batch situations), this
> must have been the reason why -cfg=blah and other -xxx=yyy options
> did work at all.

If I read the code correctly, -cfg has special handling of white space
instead of "=". I don't think other options requiring "=" ever worked
under DOS from a batch file.

> I think the deleted sentence is still true, and should not be removed.
> Maybe it should just be stressed in some way that it only applies to
> equal signs appearing in the list, but not to those in "=on" and "=off".
> 
> I remember I used to enter options that take a value that way, i.e.
> without the "=", although more recently I have reprogrammed my
> fingers.  IMO (1) it's a useful behavior to keep, (2) if it is kept it
> should not be made undocumented.  (3) It is not possible to make the
> "=" for the toggle options replaceable by white space, since
> everything after the option name is optional, but this is no great
> loss (since alternative forms exist); it just should be documented.

I am not sure how to word this so that it would be clear to someone
reading the page trying to find out how the options work. Perhaps
we could say something like "white space can sometimes be used as a
separator instead of "=", but this does not work for all options".
                             Doug

__
Doug Kaufman
Internet: address@hidden (preferred)
          address@hidden