lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Klaus Weide
Subject: Re: lynx-dev Command-line options syntax (was Command-line options and DOS)
Date: Tue, 3 Aug 1999 08:54:03 -0500 (CDT)

On Sun, 1 Aug 1999, Doug Kaufman wrote:
> On Sun, 1 Aug 1999, Klaus Weide wrote:
> [ Doug Kaufman wrote:]
> > > I propose a few changes to improve this. [...] 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).

The patch fragment in question:
 <p>No options are required, nor is a startfile argument required.
-White space may be substituted for any equal sign ('<em>=</em>')
-appearing in the option list above. [<A HREF="#ToC-Invoking">ToC</A>]
+ [<A HREF="#ToC-Invoking">ToC</A>]

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

You can easily check this for DOS, while I cannot.  My guess is that
you will find it worked, though, or if it didn't there were other
reasons (like uppercase conversion).

But handling of white space 'instead of "="' is not limited to -cfg,
it isn't so "special" but is also built into LYMain.c's parse_arg.  It
does seem to work as expected for most of the options that 'lynx
-help' lists with a "=".  Well I tested only a few.  -restrictions "?"
is an exception.

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

How about:

"White space can be used in place of equal sign separators ('<em>=</em>')
appearing in the option list above.  It can not be used in place of the
equal signs in forms like "-option=on" and "-option=off" for simple
switches and toggles, for which "-option" alone (without a value) is
valid."

More verbose, but certainly better than just saying "sometimes",
it is info needed for someone "trying to find out how the options
work" IMO.


   Klaus


reply via email to

[Prev in Thread] Current Thread [Next in Thread]