Re: DOS Options

[csampson@inetworld.net (Charles H. Sampson)]

Jeffrey Creem <jeff@thecreems.com> wrote:
> ...
> I don't know what you mean about remembering 0 being the first substring
>   of the command line? Remember from where?
> 
> ada.command_line.argument(1) certainly returns the first argument to the
> program regardless of whether it is DOS, Unix, etc. It even appears to
> handle the degenerate case of no space between the command and the 
> argument.
> 
> Perhaps I am missing the point of your question. since
> 
> my_command /option_1 /option_2
> and even
> my_command/option_1 /option_2
> 
> work such that ada.command_line.argument(1) returns /option_1
> and ada.command_line.argument(2) returns /option_2
> ...

     Just to tie a ribbon around this, here's what I've discovered since
Jeffrey and the others set me on the right path.  But first, what
Jeffrey thinks in a degenerate case I thought was a requirement.  That
is, I thought the slash-headed options had to be jammed against the
command, no spaces allowed.

     Be that as it may, I found out that, for the GNAT 3.15p version of
Ada.Command_Line, if the command name is followed immediately by a '/',
that slash and everything following it up to the first blank is
presented as Argument (1).  From that point on, blanks act as separators
between parameters.

     This has the effect that it's still necessary to write a parser for
Argument (1), something I thought Ada.Command_Line might be taking care
of.  I'm talking about the case of multiple slash-headed options jammed
against the command:

        command/x/y/z

I was hoping that Ada.Command_Line would return "/x" as Argument (1),
"/y" as Argument (2), etc.

     Is the GNAT implementation a reasonable one?  Knowing some of the
people at ACT, I suspect that they researched it fully and are doing
exactly what is expected for a DOS program.

                        Charlie

-- 
For an email response, insert "0824" between the 'c' and the 's'.