* Re: DOS Options
2007-12-19 18:00 ` Charles H. Sampson
@ 2007-12-19 19:40 ` Gautier
2007-12-19 22:59 ` Randy Brukardt
2007-12-19 22:47 ` Randy Brukardt
` (3 subsequent siblings)
4 siblings, 1 reply; 17+ messages in thread
From: Gautier @ 2007-12-19 19:40 UTC (permalink / raw)
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!
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: DOS Options
2007-12-19 19:40 ` Gautier
@ 2007-12-19 22:59 ` Randy Brukardt
2007-12-19 23:36 ` Adam Beneschan
0 siblings, 1 reply; 17+ messages in thread
From: Randy Brukardt @ 2007-12-19 22:59 UTC (permalink / raw)
"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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: DOS Options
2007-12-19 22:59 ` Randy Brukardt
@ 2007-12-19 23:36 ` Adam Beneschan
2007-12-20 22:15 ` Randy Brukardt
0 siblings, 1 reply; 17+ messages in thread
From: Adam Beneschan @ 2007-12-19 23:36 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: DOS Options
2007-12-19 23:36 ` Adam Beneschan
@ 2007-12-20 22:15 ` Randy Brukardt
0 siblings, 0 replies; 17+ messages in thread
From: Randy Brukardt @ 2007-12-20 22:15 UTC (permalink / raw)
"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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: DOS Options
2007-12-19 18:00 ` Charles H. Sampson
2007-12-19 19:40 ` Gautier
@ 2007-12-19 22:47 ` Randy Brukardt
2007-12-19 22:47 ` Randy Brukardt
` (2 subsequent siblings)
4 siblings, 0 replies; 17+ messages in thread
From: Randy Brukardt @ 2007-12-19 22:47 UTC (permalink / raw)
"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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: DOS Options
2007-12-19 18:00 ` Charles H. Sampson
2007-12-19 19:40 ` Gautier
2007-12-19 22:47 ` Randy Brukardt
@ 2007-12-19 22:47 ` Randy Brukardt
2007-12-19 22:47 ` Randy Brukardt
2007-12-19 22:47 ` Randy Brukardt
4 siblings, 0 replies; 17+ messages in thread
From: Randy Brukardt @ 2007-12-19 22:47 UTC (permalink / raw)
"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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: DOS Options
2007-12-19 18:00 ` Charles H. Sampson
` (2 preceding siblings ...)
2007-12-19 22:47 ` Randy Brukardt
@ 2007-12-19 22:47 ` Randy Brukardt
2007-12-19 22:47 ` Randy Brukardt
4 siblings, 0 replies; 17+ messages in thread
From: Randy Brukardt @ 2007-12-19 22:47 UTC (permalink / raw)
"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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: DOS Options
2007-12-19 18:00 ` Charles H. Sampson
` (3 preceding siblings ...)
2007-12-19 22:47 ` Randy Brukardt
@ 2007-12-19 22:47 ` Randy Brukardt
2007-12-21 0:39 ` Jeffrey R. Carter
4 siblings, 1 reply; 17+ messages in thread
From: Randy Brukardt @ 2007-12-19 22:47 UTC (permalink / raw)
"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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: DOS Options
2007-12-19 22:47 ` Randy Brukardt
@ 2007-12-21 0:39 ` Jeffrey R. Carter
2007-12-22 0:45 ` Randy Brukardt
0 siblings, 1 reply; 17+ messages in thread
From: Jeffrey R. Carter @ 2007-12-21 0:39 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: DOS Options
2007-12-21 0:39 ` Jeffrey R. Carter
@ 2007-12-22 0:45 ` Randy Brukardt
0 siblings, 0 replies; 17+ messages in thread
From: Randy Brukardt @ 2007-12-22 0:45 UTC (permalink / raw)
"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.
^ permalink raw reply [flat|nested] 17+ messages in thread