lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev Command-line options and DOS [patch]


From: Klaus Peter Wegge
Subject: Re: lynx-dev Command-line options and DOS [patch]
Date: Fri, 6 Aug 1999 14:12:47 +0200 (MET DST)

Doug,
> 
> On Thu, 5 Aug 1999, Klaus Peter Wegge wrote:
> 
> > > 4. The ":" is already used as a separator for options in lynx.cfg
> > Sorry, but I don't understand this discussion.
> > In one of my dos batch files (DOS 6.22) I have a line like:
> > c:\lynx -auth=abc:xyz
> > I don't have a problem with the "=" in the DOS batch file.
> > Where is the problem exactly?
> 
> The problem is with options that don't _require_ an argument, and
> which may be _optionally_ given an argument, such as -show_cursor
> (which may optionally have arguments "on" "off" "+" or "-". When the
Perhaps it would be more consistent to define, that such parameters
need an argument. ;-(
> "=" is missing, the next argument is taken as the startfile. The
> option that you give, -auth, accepts whitespace between it and its
> argument. I think that with your batch file, what is actually passed
> to lynx is:
> "c:\lynx -auth abc:xyz".
> You should be able to test this by turning echo on in the batch file.
I did so. And the result is:
c:\>c:\lynx -auth=abc:xyz -show_cursor=on
But you are right. Replacing lynx by a batch file t.bat with the only
line
echo %1 %2 - %3 %4
you will see:
c:\t -auth abc:xyz - -show_cursor on


...
> 
> It gets parsed at the first ":". Also acceptable would be:
> "-cfg:c:/lynx/lynx.cfg"
>  
> > 
> > But there is another problem in DOS.
> > The length of a commandline is restricted to 128 characters.
> > For this reason we should consider an option like
> > -file=optionfilename
> > which enables lynx to read options from an seperate file.
> 
> I think we already have this. It is the "-cfg" option. There are only
> a few options which must be given at the command line, instead of in
> lynx.cfg. The command line buffer limit of DOS should not normally be
> a problem.
You are right.

Klaus-Peter

reply via email to

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