DOS Options

DOS Options

[Charles H. Sampson]

     I've been using GNAT 3.15p for a long time to write DOS-like
project utiities to run on my Wintel desktop.  I've just come up with a
case where I'd like to implement optional parameters.  Since the utility
is DOS-like, I want to use the DOS form of optional parameters: attached
to the name of the command, separated by the '/' character.

     I don't see how to do this.  Command_Line.Argument doesn't accept a
value of 0, which I remember as being the substring of the command line
from the first non-blank up to the first suceeding blank.  The note in
A.15 says that Command_Name is the equivalent of argv (0), but in GNAT
that's really just the command name, options stripped off.

     Does anybody have any suggestions?

                        Charlie

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

Re: DOS Options

[Jeffrey Creem]

Charles H. Sampson wrote:
>      I've been using GNAT 3.15p for a long time to write DOS-like
> project utiities to run on my Wintel desktop.  I've just come up with a
> case where I'd like to implement optional parameters.  Since the utility
> is DOS-like, I want to use the DOS form of optional parameters: attached
> to the name of the command, separated by the '/' character.
> 
>      I don't see how to do this.  Command_Line.Argument doesn't accept a
> value of 0, which I remember as being the substring of the command line
> from the first non-blank up to the first suceeding blank.  The note in
> A.15 says that Command_Name is the equivalent of argv (0), but in GNAT
> that's really just the command name, options stripped off.
> 
>      Does anybody have any suggestions?
> 
>                         Charlie
> 

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

But since this is the most obvious thing I assume I am not really 
understanding your problem.

Re: DOS Options

[gautier_niouzes]

On 5 Dez., 04:34, csamp...@inetworld.net (Charles H. Sampson) wrote:
>      I've been using GNAT 3.15p for a long time to write DOS-like
> project utiities to run on my Wintel desktop.  I've just come up with a
> case where I'd like to implement optional parameters.  Since the utility
> is DOS-like, I want to use the DOS form of optional parameters: attached
> to the name of the command, separated by the '/' character.
>
>      I don't see how to do this.  Command_Line.Argument doesn't accept a
> value of 0, which I remember as being the substring of the command line
> from the first non-blank up to the first suceeding blank.  The note in
> A.15 says that Command_Name is the equivalent of argv (0), but in GNAT
> that's really just the command name, options stripped off.
>
>      Does anybody have any suggestions?

Yes: try...
You will see that the option attached to the command name appears in
Argument(1), the OS does the separation for you; nothing specific to
GNAT or Ada...
If you want an example, here is one:
  http://homepage.sunrise.ch/mysunrise/gdm/uza_html/unzipada__adb.htm

The commands
  unzipada/t test.zip
or
  unzipada /t test.zip
or
  unzipada -t test.zip
work as expected

HTH
G.

Re: DOS Options

[Stephen Leake]

csampson@inetworld.net (Charles H. Sampson) writes:

>      I've been using GNAT 3.15p for a long time to write DOS-like
> project utiities to run on my Wintel desktop.  I've just come up with a
> case where I'd like to implement optional parameters.  Since the utility
> is DOS-like, I want to use the DOS form of optional parameters: attached
> to the name of the command, separated by the '/' character.
>
>      Does anybody have any suggestions?
>
>                         Charlie

You'll have to post some specific examples, both of actual command
lines that you want to handle, and of the Ada code you have tried to
use to handle those parameters.

I don't use the DOS command line, but I have dealt with several
different styles of command-line parameter parsers.

-- 
-- Stephe

Re: DOS Options

[Charles H. Sampson]

     Well, it look like it's back to the drawing board when I get to the
office tomorrow.  It never occurred to me that command line parsing
would split off the slash-headed options and present them as it presents
the "regular" parameters.  When I saw that they weren't there, still
attached, as part of Command_Name, I thought they were lost and didn't
look any further.  Thanks to all for straightening me out.

     To answer Jeffrey's question, I used the word "remember" carefully,
not meaning to imply that my memory was faultless.  So far in my career,
I've only had to write one piece of C code, it was about 10 lines long,
and it didn't solve the problem that forced me to try it.  Thus it never
went into production.  So I've got a serious deficiency in hands-on C
experience, which I wear as a badge of honor.

                                   Charlie

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

Re: DOS Options

[anon]

--
-- c.adb
--

--
-- Sample run:
-- c/f 
-- Yields:
--    Command_Name => c
--    Argument ( 1 ) => /f
--
with Ada.Integer_Text_IO ;
use  Ada.Integer_Text_IO ;
with Ada.Text_IO ;
use Ada.Text_IO ;

With Ada.Command_Line ;
use  Ada.Command_Line ;

procedure c is

begin

                             -- Argument ( 0 )
  Put ( "Command => " ) ;
  Put_Line ( Command_Name ) ;
                             -- Argument ( 1..?? )
  if Argument_Count = 0 then
    Put_Line ( "No command options" ) ;
  else
    Put_Line ( "Command options" ) ;
    for Index in 1..Argument_Count loop
      Put ( "    " ) ;
      Put ( Index ) ;
      Put ( " => " ) ;
      Put_Line ( Argument ( Index ) ) ;
    end loop ;
  end if ;

end c ;

In <1i8m324.g6pon43ql1ogN%csampson@inetworld.net>, csampson@inetworld.net (Charles H. Sampson) writes:
>     I've been using GNAT 3.15p for a long time to write DOS-like
>project utiities to run on my Wintel desktop.  I've just come up with a
>case where I'd like to implement optional parameters.  Since the utility
>is DOS-like, I want to use the DOS form of optional parameters: attached
>to the name of the command, separated by the '/' character.
>
>     I don't see how to do this.  Command_Line.Argument doesn't accept a
>value of 0, which I remember as being the substring of the command line
>from the first non-blank up to the first suceeding blank.  The note in
>A.15 says that Command_Name is the equivalent of argv (0), but in GNAT
>that's really just the command name, options stripped off.
>
>     Does anybody have any suggestions?
>
>                        Charlie
>
>-- 
>For an email response, insert "0824" between the 'c' and the 's'.

Re: DOS Options

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

Re: DOS Options

[Gautier]

Charles H. Sampson:

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

Sure!

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

ACT doesn't support DOS since version 3.07p or maybe even before.
The last on-purpose packaged version of GNAT (specifically as a GNAT Public 
version, not a GCC version) for DOS is 3.10p.
Your 3.15p is certainly the Windows version, and what you are seeing is a Win32 
console output. Indeed, you need to congratulate Microsoft which decided to 
parse and separate the arguments in Win32 in a fashion consistent with DOS - 
adding the parsing of filenames containing spaces, enclosed by "". 
Ada.Command_Line.Argument(i) just gives the "ith" argument from the system, as 
the system wants to give it, that's it.
Running the following Turbo Pascal (authentic DOS) code:

   VAR i:Word;BEGIN FOR i:=1 TO paramcount DO WriteLn(i,':',paramstr(i))END.

you get exactly the same (expected, even if not ideal) behaviour:

C:\TEMP>show_cmd/x/y/z /a/b/c
1:/x/y/z
2:/a/b/c

HTH
______________________________________________________________
Gautier         -- http://www.mysunrise.ch/users/gdm/index.htm
Ada programming -- http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, e-mail address on the Web site!

Re: DOS Options

[Randy Brukardt]

"Charles H. Sampson" <csampson@inetworld.net> wrote in message
news:1i9d4ab.twgszk4zp5evN%csampson@inetworld.net...
...
>      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.

Ada.Command_Line is a thinly-veiled wrapper on the normal C "argv/argc"
mechanism. I think most Ada compilers simply copy that mechanism (that's
pretty much a requirement on Unix, and it is better for portability on all
platforms). The fact that that mechanism isn't very useful is not considered
relevant. (And yes, for the record, Janus/Ada does exactly that for
Ada.Command_Line. We don't even bother to use Ada.Command_Line for the
command line processing of our compiler and tools; it is just as easy to
process starting from the original string.)

                       Randy.

Re: DOS Options

[Randy Brukardt]

"Charles H. Sampson" <csampson@inetworld.net> wrote in message
news:1i9d4ab.twgszk4zp5evN%csampson@inetworld.net...
...
>      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.

Ada.Command_Line is a thinly-veiled wrapper on the normal C "argv/argc"
mechanism. I think most Ada compilers simply copy that mechanism (that's
pretty much a requirement on Unix, and it is better for portability on all
platforms). The fact that that mechanism isn't very useful is not considered
relevant. (And yes, for the record, Janus/Ada does exactly that for
Ada.Command_Line. We don't even bother to use Ada.Command_Line for the
command line processing of our compiler and tools; it is just as easy to
process starting from the original string.)

                       Randy.

Re: DOS Options

[Randy Brukardt]

"Charles H. Sampson" <csampson@inetworld.net> wrote in message
news:1i9d4ab.twgszk4zp5evN%csampson@inetworld.net...
...
>      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.

Ada.Command_Line is a thinly-veiled wrapper on the normal C "argv/argc"
mechanism. I think most Ada compilers simply copy that mechanism (that's
pretty much a requirement on Unix, and it is better for portability on all
platforms). The fact that that mechanism isn't very useful is not considered
relevant. (And yes, for the record, Janus/Ada does exactly that for
Ada.Command_Line. We don't even bother to use Ada.Command_Line for the
command line processing of our compiler and tools; it is just as easy to
process starting from the original string.)

                       Randy.

Re: DOS Options

[Randy Brukardt]

"Charles H. Sampson" <csampson@inetworld.net> wrote in message
news:1i9d4ab.twgszk4zp5evN%csampson@inetworld.net...
...
>      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.

Ada.Command_Line is a thinly-veiled wrapper on the normal C "argv/argc"
mechanism. I think most Ada compilers simply copy that mechanism (that's
pretty much a requirement on Unix, and it is better for portability on all
platforms). The fact that that mechanism isn't very useful is not considered
relevant. (And yes, for the record, Janus/Ada does exactly that for
Ada.Command_Line. We don't even bother to use Ada.Command_Line for the
command line processing of our compiler and tools; it is just as easy to
process starting from the original string.)

                       Randy.

Re: DOS Options

[Randy Brukardt]

"Gautier" <gautier@fakeaddress.nil> wrote in message
news:476973a3$1_5@news.bluewin.ch...
...
> Your 3.15p is certainly the Windows version, and what you are seeing is a
Win32
> console output. Indeed, you need to congratulate Microsoft which decided
to
> parse and separate the arguments in Win32 in a fashion consistent with
DOS -
> adding the parsing of filenames containing spaces, enclosed by "".
> Ada.Command_Line.Argument(i) just gives the "ith" argument from the
system, as
> the system wants to give it, that's it.

I have no idea what you are talking about. Both MS-DOS and Win32 only
provide a single string as the result of the command line -- the system
provides no parsing whatsoever. For Win32, the function is GetCommandLine.
In DOS, you had to grab the string from the memory of your executable
process -- there isn't even a function to get it.

Parsing is something that was provided by C compilers on both of those
platforms. The was generally defined to be compatible with the Unix C
implementations (since that is how C was originally defined). Janus/Ada
never did any parsing at all (just returning a single string, even on Unix);
if we had done some, it would have separated the options out as the original
OP suggested. But that would be fairly complex to do, we never figured out a
good way to encapsulate it for our products, so we didn't make that library
available to our customers.

I'm a little stunned that Turbo Pascal would have copied this useless
parsing definition, given that they had to write all of the code themselves.
But perhaps it is the same reason that we ended up doing so for
Ada.Command_Line: to be compatible with C compilers and/or (possible) Unix
versions of your product.

In any event, Microsoft's OSes have had nothing whatsoever to do the the
parsing of command lines.
All of the code to parse the command line appears inside of Ada.Command_Line
for a Windows implementation (or perhaps some lower-level library intended
to emulate Unix behavior).

                          Randy.

Re: DOS Options

[Adam Beneschan]

On Dec 19, 2:59 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> "Gautier" <gaut...@fakeaddress.nil> wrote in message
>
> news:476973a3$1_5@news.bluewin.ch...
> ...
>
> > Your 3.15p is certainly the Windows version, and what you are seeing is a
> Win32
> > console output. Indeed, you need to congratulate Microsoft which decided
> to
> > parse and separate the arguments in Win32 in a fashion consistent with
> DOS -
> > adding the parsing of filenames containing spaces, enclosed by "".
> > Ada.Command_Line.Argument(i) just gives the "ith" argument from the
> system, as
> > the system wants to give it, that's it.
>
> I have no idea what you are talking about. Both MS-DOS and Win32 only
> provide a single string as the result of the command line -- the system
> provides no parsing whatsoever. For Win32, the function is GetCommandLine.
> In DOS, you had to grab the string from the memory of your executable
> process -- there isn't even a function to get it.

Windows does appear to have a CommandLineToArgvW function that parses
the command line (or whatever string you give it).  I don't know
whether GNAT uses it.  I'm pretty sure that not all C compilers use
it---the MINGW32 version, I believe, does its own parsing, in whatever
startup routine is linked into the program before main() is called.

                                -- Adam

Re: DOS Options

[Randy Brukardt]

"Adam Beneschan" <adam@irvine.com> wrote in message
news:4c374a25-562c-4b8e-9770-07868bd88f15@e23g2000prf.googlegroups.com...
> On Dec 19, 2:59 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> > "Gautier" <gaut...@fakeaddress.nil> wrote in message
> >
> > news:476973a3$1_5@news.bluewin.ch...
> > ...
> >
> > > Your 3.15p is certainly the Windows version, and what you are seeing
is a
> > Win32
> > > console output. Indeed, you need to congratulate Microsoft which
decided
> > to
> > > parse and separate the arguments in Win32 in a fashion consistent with
> > DOS -
> > > adding the parsing of filenames containing spaces, enclosed by "".
> > > Ada.Command_Line.Argument(i) just gives the "ith" argument from the
> > system, as
> > > the system wants to give it, that's it.
> >
> > I have no idea what you are talking about. Both MS-DOS and Win32 only
> > provide a single string as the result of the command line -- the system
> > provides no parsing whatsoever. For Win32, the function is
GetCommandLine.
> > In DOS, you had to grab the string from the memory of your executable
> > process -- there isn't even a function to get it.
>
> Windows does appear to have a CommandLineToArgvW function that parses
> the command line (or whatever string you give it).  I don't know
> whether GNAT uses it.  I'm pretty sure that not all C compilers use
> it---the MINGW32 version, I believe, does its own parsing, in whatever
> startup routine is linked into the program before main() is called.

Fascinating; never noticed that one. I doubt anything much uses it, though,
because it isn't supported on Windows 95/98/ME, so any compiler runtime that
used it would have to be almost brand-new. (It would have been nasty to make
programs that don't run on older Windows systems just to use a function that
is easy to write yourself. Not as big of an issue today, but I doubt
compiler vendors are rewriting their runtime to purposely break something
that previously worked!)

                              Randy.

Re: DOS Options

[Jeffrey R. Carter]

Randy Brukardt wrote:
> "Charles H. Sampson" <csampson@inetworld.net> wrote in message
> news:1i9d4ab.twgszk4zp5evN%csampson@inetworld.net...
> ...
>>      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.
> 
> Ada.Command_Line is a thinly-veiled wrapper on the normal C "argv/argc"
> mechanism. I think most Ada compilers simply copy that mechanism (that's
> pretty much a requirement on Unix, and it is better for portability on all
> platforms). The fact that that mechanism isn't very useful is not considered
> relevant. (And yes, for the record, Janus/Ada does exactly that for
> Ada.Command_Line. We don't even bother to use Ada.Command_Line for the
> command line processing of our compiler and tools; it is just as easy to
> process starting from the original string.)
> 
>                        Randy.
> 
> 

This got posted 5 times. That's a record, even for you.

-- 
Jeff Carter
"We use a large, vibrating egg."
Annie Hall
44

Re: DOS Options

[Randy Brukardt]

"Jeffrey R. Carter" <spam.jrcarter.not@acm.nospam.org> wrote in message
news:eXDaj.259984$Fc.65173@attbi_s21...
> Randy Brukardt wrote:
...
> > Ada.Command_Line is a thinly-veiled wrapper on the normal C "argv/argc"
> > mechanism. I think most Ada compilers simply copy that mechanism (that's
> > pretty much a requirement on Unix, and it is better for portability on
all
> > platforms). The fact that that mechanism isn't very useful is not
considered
> > relevant. (And yes, for the record, Janus/Ada does exactly that for
> > Ada.Command_Line. We don't even bother to use Ada.Command_Line for the
> > command line processing of our compiler and tools; it is just as easy to
> > process starting from the original string.)
> >
> >                        Randy.
> >
> >
>
> This got posted 5 times. That's a record, even for you.

I didn't notice that each time I wrote a message (and I wrote a bunch that
day), it tried again to post that message and failed (well, failed on this
end, obviously it didn't *actually* fail). Normally, it would just try when
I close the newsreader and then again when I reopen it (leading to a double
posting at most). That behavior hasn't repeated (that goodness), but I'm not
at all sure what is going on in any case. Hopefully it will go away and stay
that way...

                       Randy.