Ada.Command_Line.Argument_Count question

Ada.Command_Line.Argument_Count question

[@ 2009-09-15 20:58 UTC (permalink / raw)]

The RM has this to say about Argument_Count:

"If the external execution environment supports passing arguments to a 
program, then Argument_Count returns the number of arguments passed to 
the program invoking the function. Otherwise it returns 0. The meaning 
of �number of arguments� is implementation defined."

I'm wondering what that last sentence mean? Is the RM trying to tell me 
that Argument_Count cannot be trusted to yield the same result on 
different systems (Unix, BSD, Windows, Linux and so on)?

Or am I missing the point?

-- 
Regards,
Thomas L�cke

Email: tl at ada-dk.org
Web: http:ada-dk.org
IRC nick: ThomasLocke

Re: Ada.Command_Line.Argument_Count question

[Gautier write-only]

On 15 sep, 22:58, Thomas Løcke wrote:
> The RM has this to say about Argument_Count:
>
> "If the external execution environment supports passing arguments to a
> program, then Argument_Count returns the number of arguments passed to
> the program invoking the function. Otherwise it returns 0. The meaning
> of “number of arguments” is implementation defined."
>
> I'm wondering what that last sentence mean? Is the RM trying to tell me
> that Argument_Count cannot be trusted to yield the same result on
> different systems (Unix, BSD, Windows, Linux and so on)?

Perhaps... And it the behaviour is compiler-dependent too!
Some systems will give 2 for ["a b" c]; others, 3 (maybe only DOS on
that!).
Some compilers will always return [*.adb] as is, others (GNAT) will
return one argument for each file corresponding to that pattern, or
still "*.adb" if there is no such file!
Always interesting to test a bit with that:

-- Displays the arguments given

with Ada.Command_Line;                  use Ada.Command_Line;
with Ada.Text_IO;                       use Ada.Text_IO;

procedure Args is
begin
  for I in 1..Argument_Count loop
    Put_Line(Integer'Image(I) & " [" & Argument(I) & ']');
  end loop;
  Put("Press Enter"); Skip_Line;
end;

Cheers
_________________________________________________________
Gautier's Ada programming -- http://sf.net/users/gdemont/
NB: For a direct answer, e-mail address on the Web site!

Re: Ada.Command_Line.Argument_Count question

[Adam Beneschan]

On Sep 15, 1:58 pm, Thomas Løcke <"tl at ada-dk.org"> wrote:
> The RM has this to say about Argument_Count:
>
> "If the external execution environment supports passing arguments to a
> program, then Argument_Count returns the number of arguments passed to
> the program invoking the function. Otherwise it returns 0. The meaning
> of “number of arguments” is implementation defined."
>
> I'm wondering what that last sentence mean? Is the RM trying to tell me
> that Argument_Count cannot be trusted to yield the same result on
> different systems (Unix, BSD, Windows, Linux and so on)?

You can probably trust that Argument_Count will give the same result
on any Unix, BSD, Linux, or other Unix-like OS (Solaris, HP-UX, IRIX,
etc.), since the mechanisms that the shell uses for passing arguments
to programs is the same for all of them.  This is assuming the shells
handle the argument lines the same way.  Obviously, different shells
don't parse things the same way.  In fact, you have to be careful
about how you define "yield the same result"---yield the same result
under what conditions??  If you type the command

   application {file1,file2,file3}.dat

the argument count should be 3 if the shell interprets the curly
braces to convert the line to "file1.dat file2.dat file3.dat", but 1
if it doesn't (older Bourne shells don't).  So you could get a
different Argument_Count even on the *same* system, if you use the
same command line in a different shell.

Windows uses a totally different "shell" (Command Prompt) so you can't
expect it to work the same.  In practice, I don't believe Windows
breaks down the command line at all (maybe later versions do, I'm not
sure); it just makes the whole argument string available to the
program as one string (via GetCommandLine).  It's up to the
implementation to determine what to do with this string.


> Or am I missing the point?

Possibly.  The reason the meaning of "number of arguments" is
implementation-defined is that the language says nothing at all about
what an "argument" is or how it gets into the program.  The language
can't even assume that "arguments" will be passed in from a "command
line"; they could be passed in from separate boxes in a GUI window, or
created in an array by another program that executes the application,
or set up by rotating dials manually on a control panel for all we
know.

                               -- Adam

Re: Ada.Command_Line.Argument_Count question

[@ 2009-09-16 6:20 UTC (permalink / raw)]

Adam Beneschan wrote:
> You can probably trust that Argument_Count will give the same result
> on any Unix, BSD, Linux, or other Unix-like OS (Solaris, HP-UX, IRIX,
> etc.), since the mechanisms that the shell uses for passing arguments
> to programs is the same for all of them.  This is assuming the shells
> handle the argument lines the same way.  Obviously, different shells
> don't parse things the same way.  In fact, you have to be careful
> about how you define "yield the same result"---yield the same result
> under what conditions??  If you type the command
> 
>    application {file1,file2,file3}.dat
> 
> the argument count should be 3 if the shell interprets the curly
> braces to convert the line to "file1.dat file2.dat file3.dat", but 1
> if it doesn't (older Bourne shells don't).  So you could get a
> different Argument_Count even on the *same* system, if you use the
> same command line in a different shell.
> 
> Windows uses a totally different "shell" (Command Prompt) so you can't
> expect it to work the same.  In practice, I don't believe Windows
> breaks down the command line at all (maybe later versions do, I'm not
> sure); it just makes the whole argument string available to the
> program as one string (via GetCommandLine).  It's up to the
> implementation to determine what to do with this string.
> 
> 
>> Or am I missing the point?
> 
> Possibly.  The reason the meaning of "number of arguments" is
> implementation-defined is that the language says nothing at all about
> what an "argument" is or how it gets into the program.  The language
> can't even assume that "arguments" will be passed in from a "command
> line"; they could be passed in from separate boxes in a GUI window, or
> created in an array by another program that executes the application,
> or set up by rotating dials manually on a control panel for all we
> know.

Adam, thank you for this very thorough explanation.

I guess this means that program arguments should be treated as slippery 
litlle buggers, who cannot be trusted.  :o)

-- 
Regards,
Thomas L�cke

Email: tl at ada-dk.org
Web: http:ada-dk.org
IRC nick: ThomasLocke

Re: Ada.Command_Line.Argument_Count question

[@ 2009-09-16 6:21 UTC (permalink / raw)]

Gautier write-only wrote:
> Perhaps... And it the behaviour is compiler-dependent too!
> Some systems will give 2 for ["a b" c]; others, 3 (maybe only DOS on
> that!).
> Some compilers will always return [*.adb] as is, others (GNAT) will
> return one argument for each file corresponding to that pattern, or
> still "*.adb" if there is no such file!

Just as I thought, and feared.   :D

Thank you very much for the help Gautier.

-- 
Regards,
Thomas L�cke

Email: tl at ada-dk.org
Web: http:ada-dk.org
IRC nick: ThomasLocke

Re: Ada.Command_Line.Argument_Count question

[Jeffrey R. Carter]

Thomas L�cke wrote:
> 
> I'm wondering what that last sentence mean? Is the RM trying to tell me 
> that Argument_Count cannot be trusted to yield the same result on 
> different systems (Unix, BSD, Windows, Linux and so on)?

Consider the argument list

/a/b/c

On some systems, this is 3 arguments: "a", "b", and "c". '/' is used to 
introduce an argument.

On other systems, this is a single argument representing an absolute file path. 
'/' is the directory separator.

On yet other systems, this might be interpreted in a completely different way.

-- 
Jeff Carter
"My dear Mrs. Hemoglobin, when I first saw you, I
was so enamored with your beauty I ran to the basket,
jumped in, went down to the city, and bought myself a
wedding outfit."
Never Give a Sucker an Even Break
111

Re: Ada.Command_Line.Argument_Count question

[Keith Thompson]

Gautier write-only <gautier_niouzes@hotmail.com> writes:
> On 15 sep, 22:58, Thomas Løcke wrote:
>> The RM has this to say about Argument_Count:
>> "If the external execution environment supports passing arguments to a
>> program, then Argument_Count returns the number of arguments passed to
>> the program invoking the function. Otherwise it returns 0. The meaning
>> of “number of arguments” is implementation defined."
>>
>> I'm wondering what that last sentence mean? Is the RM trying to tell me
>> that Argument_Count cannot be trusted to yield the same result on
>> different systems (Unix, BSD, Windows, Linux and so on)?
>
> Perhaps... And it the behaviour is compiler-dependent too!
> Some systems will give 2 for ["a b" c]; others, 3 (maybe only DOS on
> that!).
> Some compilers will always return [*.adb] as is, others (GNAT) will
> return one argument for each file corresponding to that pattern, or
> still "*.adb" if there is no such file!
[...]

The behavior you describe has nothing to do with the compiler, at
least not on Unix-like systems.  If you type
    ./my_program *.adb
in a Unix shell, my_program will see a list of file names; it will
have no way to know that the list is the result of expanding a
wildcard expression.  All the processing happens in the shell.  And of
course programs can be invoked by other programs, not just by the
shell.

On other systems, though, the Ada.Command_Line implementation might
(optionally?) do some additional processing.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Re: Ada.Command_Line.Argument_Count question

[John McCabe]

On Tue, 15 Sep 2009 22:58:49 +0200, Thomas L�cke <"tl at ada-dk.org">
wrote:

>The RM has this to say about Argument_Count:
>
>"If the external execution environment supports passing arguments to a 
>program, then Argument_Count returns the number of arguments passed to 
>the program invoking the function. Otherwise it returns 0. The meaning 
>of �number of arguments� is implementation defined."
>
>I'm wondering what that last sentence mean? Is the RM trying to tell me 
>that Argument_Count cannot be trusted to yield the same result on 
>different systems (Unix, BSD, Windows, Linux and so on)?
>
>Or am I missing the point?

Are you also thinking of whether the program itself counts as an
argument?

For example if, on the command line, I type:

prog1.exe a b c

Does Argument_Count() return 3 or 4? I haven't looked at this
paragraph in detail, or what surrounds it, but "the number of
arguments passed to the program invoking the function" sounds a bit
vague. Is the "program invoking the function" the shell, or the
program you're running?

John

Re: Ada.Command_Line.Argument_Count question

[sjw]

On Sep 17, 2:50 pm, John McCabe <j...@nospam.assen.demon.co.uk> wrote:

> For example if, on the command line, I type:
>
> prog1.exe a b c
>
> Does Argument_Count() return 3 or 4? I haven't looked at this
> paragraph in detail, or what surrounds it, but "the number of
> arguments passed to the program invoking the function" sounds a bit
> vague. Is the "program invoking the function" the shell, or the
> program you're running?

3.

The program you're running.

Re: Ada.Command_Line.Argument_Count question

[John McCabe]

On Thu, 17 Sep 2009 22:12:17 -0700 (PDT), sjw <simon.j.wright@mac.com>
wrote:

>On Sep 17, 2:50�pm, John McCabe <j...@nospam.assen.demon.co.uk> wrote:
>
>> For example if, on the command line, I type:
>>
>> prog1.exe a b c
>>
>> Does Argument_Count() return 3 or 4? I haven't looked at this
>> paragraph in detail, or what surrounds it, but "the number of
>> arguments passed to the program invoking the function" sounds a bit
>> vague. Is the "program invoking the function" the shell, or the
>> program you're running?
>
>3.

>The program you're running.

For all implementations?

I see that Ada.Command_Line.Command_Name returns the name of the
program that's been run. On Gnat at least it all makes sense. Compared
to C++ (MSVC) on Win32 for:

printargs.exe 1 2 3

I get..
               Ada            C++
Argument Count 3              4
command name   printargs.exe  equiv. to argv[0]
argument 1     1              1
argument 2     2              2
argument 3     3              3

I guess, from the Annotated ARM, section A.15(22) & A.15(22a).

Re: Ada.Command_Line.Argument_Count question

[Robert A Duff]

John McCabe <john@nospam.assen.demon.co.uk> writes:

> On Thu, 17 Sep 2009 22:12:17 -0700 (PDT), sjw <simon.j.wright@mac.com>
> wrote:
>
>>On Sep 17, 2:50�pm, John McCabe <j...@nospam.assen.demon.co.uk> wrote:
>>
>>> For example if, on the command line, I type:
>>>
>>> prog1.exe a b c
>>>
>>> Does Argument_Count() return 3 or 4? I haven't looked at this
>>> paragraph in detail, or what surrounds it, but "the number of
>>> arguments passed to the program invoking the function" sounds a bit
>>> vague. Is the "program invoking the function" the shell, or the
>>> program you're running?
>>
>>3.
>
>>The program you're running.
>
> For all implementations?

For all reasonable implementations.  It is possible to create a
conforming Ada implementation that does something weird, because
the RM leaves all this implementation-defined.  It has to, because
we can't know about all operating systems.  But for any operating
system that supports command-line arguments, you can count on the
Ada implementation NOT including the command name itself as one
of the arguments.

> I see that Ada.Command_Line.Command_Name returns the name of the
> program that's been run. On Gnat at least it all makes sense. Compared
> to C++ (MSVC) on Win32 for:
>
> printargs.exe 1 2 3
>
> I get..
>                Ada            C++
> Argument Count 3              4
> command name   printargs.exe  equiv. to argv[0]
> argument 1     1              1
> argument 2     2              2
> argument 3     3              3
>
> I guess, from the Annotated ARM, section A.15(22) & A.15(22a).

Right.

- Bob

Re: Ada.Command_Line.Argument_Count question

[John McCabe]

On Fri, 18 Sep 2009 18:16:15 -0400, Robert A Duff
<bobduff@shell01.TheWorld.com> wrote:

>>>> Does Argument_Count() return 3 or 4? I haven't looked at this
>>>> paragraph in detail, or what surrounds it, but "the number of
>>>> arguments passed to the program invoking the function" sounds a bit
>>>> vague. Is the "program invoking the function" the shell, or the
>>>> program you're running?

>>>3.

>>>The program you're running.

>> For all implementations?

>For all reasonable implementations.  It is possible to create a
>conforming Ada implementation that does something weird, because
>the RM leaves all this implementation-defined.  It has to, because
>we can't know about all operating systems.

Really? Surely the language here is providing a layer of abstraction
from the operating system so it should be able to be definitive about
whether the program name should be included in the argument count or
the list of arguments in Ada.Command_Line?

Re: Ada.Command_Line.Argument_Count question

[Dmitry A. Kazakov]

On Mon, 21 Sep 2009 16:09:21 +0100, John McCabe wrote:

> On Fri, 18 Sep 2009 18:16:15 -0400, Robert A Duff
> <bobduff@shell01.TheWorld.com> wrote:
> 
>>>>> Does Argument_Count() return 3 or 4? I haven't looked at this
>>>>> paragraph in detail, or what surrounds it, but "the number of
>>>>> arguments passed to the program invoking the function" sounds a bit
>>>>> vague. Is the "program invoking the function" the shell, or the
>>>>> program you're running?
> 
>>>>3.
> 
>>>>The program you're running.
> 
>>> For all implementations?
> 
>>For all reasonable implementations.  It is possible to create a
>>conforming Ada implementation that does something weird, because
>>the RM leaves all this implementation-defined.  It has to, because
>>we can't know about all operating systems.
> 
> Really? Surely the language here is providing a layer of abstraction
> from the operating system so it should be able to be definitive about
> whether the program name should be included in the argument count or
> the list of arguments in Ada.Command_Line?

Yes, but it certainly not as an argument of. If this functionality has to
be supported then as a set of separate functions, like:

Get_Image_Name (the file containing the program image),
Get_Install_Name (the name used to invoke the program),
Get_Command_Line (the user input caused execution of this instance),
Get_Instance_Count (number of instances running)

etc.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada.Command_Line.Argument_Count question

[sjw]

On Sep 21, 4:09 pm, John McCabe <j...@nospam.assen.demon.co.uk> wrote:

> Really? Surely the language here is providing a layer of abstraction
> from the operating system so it should be able to be definitive about
> whether the program name should be included in the argument count or
> the list of arguments in Ada.Command_Line?

There's a very strong hint at the end of this page ...
http://www.adaic.com/standards/05aarm/html/AA-A-15.html

Re: Ada.Command_Line.Argument_Count question

[John McCabe]

On Mon, 21 Sep 2009 12:44:15 -0700 (PDT), sjw <simon.j.wright@mac.com>
wrote:

>On Sep 21, 4:09�pm, John McCabe <j...@nospam.assen.demon.co.uk> wrote:
>
>> Really? Surely the language here is providing a layer of abstraction
>> from the operating system so it should be able to be definitive about
>> whether the program name should be included in the argument count or
>> the list of arguments in Ada.Command_Line?
>
>There's a very strong hint at the end of this page ...
>http://www.adaic.com/standards/05aarm/html/AA-A-15.html

While you're right of course, I just don't get a great feeling from
that chapter. Perhaps it would have been nice to have an explanation
at the point where it says 'the "number of arguments" is
implementation defined'.

Still, never mind.

Re: Ada.Command_Line.Argument_Count question

[Gautier write-only]

On 16 Sep., 20:43, Keith Thompson <ks...@mib.org> wrote:

[about names with wildcards expanded or not into separate arguments]

> The behavior you describe has nothing to do with the compiler, at
> least not on Unix-like systems.  If you type
>     ./my_program *.adb
> in a Unix shell, my_program will see a list of file names; it will
> have no way to know that the list is the result of expanding a
> wildcard expression.  All the processing happens in the shell.  And of
> course programs can be invoked by other programs, not just by the
> shell.

There are exceptions to that. If you type:
unzip archive.zip *.adb
the "*.adb" will, even on Unix, fortunately *not* be expanded...

> On other systems, though, the Ada.Command_Line implementation might
> (optionally?) do some additional processing.

On Windows, the shell doesn't seem to do the expansion, but on the run-
time library side, GNAT does it and Aonix doesn't...
_________________________________________________________
Gautier's Ada programming -- http://sf.net/users/gdemont/
NB: For a direct answer, e-mail address on the Web site!

Re: Ada.Command_Line.Argument_Count question

[Hyman Rosen]

Gautier write-only wrote:
> There are exceptions to that. If you type:
> unzip archive.zip *.adb
> the "*.adb" will, even on Unix, fortunately *not* be expanded...

Why do you believe this to be true? I believe that the *.adb will
only not be expanded if there happen to be no files in the current
directory which match that pattern, and even then, only in certain
kinds of shells. Those based on the c-shell can give you an error
and not execute the program at all.

If you don't want filename expansion in UNIX, just quote:
     unzip archive.zip "*.adb"

Re: Ada.Command_Line.Argument_Count question

[Gautier write-only]

On 22 sep, 22:00, Hyman Rosen <hyro...@mail.com> wrote:
> Gautier write-only wrote:
> > There are exceptions to that. If you type:
> > unzip archive.zip *.adb
> > the "*.adb" will, even on Unix, fortunately *not* be expanded...
>
> Why do you believe this to be true?

Because I've tested it just before posting: Linux (Fedora 8), GNU bash
3.2.25.
But maybe there is a subtle difference between Linux and UNIX on that
point ?

Gautier

Re: Ada.Command_Line.Argument_Count question

[Adam Beneschan]

On Sep 22, 5:20 pm, Gautier write-only <gautier_niou...@hotmail.com>
wrote:
> On 22 sep, 22:00, Hyman Rosen <hyro...@mail.com> wrote:
>
> > Gautier write-only wrote:
> > > There are exceptions to that. If you type:
> > > unzip archive.zip *.adb
> > > the "*.adb" will, even on Unix, fortunately *not* be expanded...
>
> > Why do you believe this to be true?
>
> Because I've tested it just before posting: Linux (Fedora 8), GNU bash
> 3.2.25.

But did you read the rest of Hyman's sentence?  I just tested it too,
and "unzip archive *.adb" WILL expand *.adb, if there any *.adb files
existing in the current directory.  And csh won't work whether or not
there are *.adb files.  So it's definitely not correct to say that
*.adb won't be expanded on Unix, because "Unix" is not a synonym for
"Bourne shell".


> But maybe there is a subtle difference between Linux and UNIX on that
> point ?

I don't think so.

                                -- Adam

Re: Ada.Command_Line.Argument_Count question

[Hyman Rosen]

Adam Beneschan wrote:
> "Unix" is not a synonym for "Bourne shell".

Just to make things clear, all "normal" UNIX (and Linux)
shells will expand '*.adb' into a list of files if there
are files in the current directory which match the pattern.
They differ in what they do if there are no such files.
Bourne shell and its variants (ksh, bash, etc.) will pass
'*.adb' literally as an argument to the command. Csh and
its variants (tcsh, zsh, etc.) will issue an error message
and not execute the command at all. Some shells also allow
you to configure this behavior to taste.

For formalists who wonder why such a pattern shouldn't
"expand" to nothing when no files match, it's because UNIX
commands tend to be written to either process a list of files
or else standard input when no files are supplied.

Re: Ada.Command_Line.Argument_Count question

[Gautier write-only]

On 23 sep, 03:07, Adam Beneschan <a...@irvine.com> wrote:

> But did you read the rest of Hyman's sentence?  I just tested it too,
> and "unzip archive *.adb" WILL expand *.adb, if there any *.adb files
> existing in the current directory.

I was wrong, you are right. Just forgot to test *with* an .adb file
around...
I was disturbed that unzip (maybe other tools ?) won't give a warning
(maybe can't, because they can't know ?) when receiving the unexpanded
'*.adb' and expands its way, using the zip archive's name list.

Gautier

Re: Ada.Command_Line.Argument_Count question

[Björn Persson]

Gautier write-only wrote:
> I was disturbed that unzip (maybe other tools ?) won't give a warning
> (maybe can't, because they can't know ?) when receiving the unexpanded
> '*.adb' and expands its way, using the zip archive's name list.

I don't understand what you think unzip should warn about. Warning about a 
strange looking filename with an asterisk in it makes no sense, as wildcards 
are a feature that has been added to unzip because it's useful.

You might argue that programs that have their own pattern matching features 
should use a different set of special characters to distinguish the patterns 
from those that the shell expands, but that's a bad idea in my opinion. 
Having multiple different syntaxes makes it hard to remember when to use 
which syntax.

-- 
Bj�rn Persson
PGP key A88682FD

Re: Ada.Command_Line.Argument_Count question

[Adam Beneschan]

On Sep 23, 5:31 pm, Björn Persson <bj...@xn--rombobjrn-67a.se> wrote:

> You might argue that programs that have their own pattern matching features
> should use a different set of special characters to distinguish the patterns
> from those that the shell expands, but that's a bad idea in my opinion.
> Having multiple different syntaxes makes it hard to remember when to use
> which syntax.

Multiple syntaxes is a bad idea, but I've always wanted a way to add a
flag to certain executables to tell the shell "don't expand wildcards
when running this executable".  Then you could actually write a
command of the sort that exists on other OS's:

   rename *.ada *.adb

(The shell wouldn't expand either parameter.  The "rename" program
would be responsible for searching for files that matched the first
parameter.  Ideally, this would be accomplished by a library routine
that the shell also uses when it does expand.)

                                    -- Adam

Re: Ada.Command_Line.Argument_Count question

[Stephen Leake]

Adam Beneschan <adam@irvine.com> writes:

> On Sep 23, 5:31�pm, Bj�rn Persson <bj...@xn--rombobjrn-67a.se> wrote:
>
>> You might argue that programs that have their own pattern matching features
>> should use a different set of special characters to distinguish the patterns
>> from those that the shell expands, but that's a bad idea in my opinion.
>> Having multiple different syntaxes makes it hard to remember when to use
>> which syntax.
>
> Multiple syntaxes is a bad idea, but I've always wanted a way to add a
> flag to certain executables to tell the shell "don't expand wildcards
> when running this executable".  

That flag exists, but it's a shell feature, of course, since you are
telling the shell to not do something. It's called "quotes".

> Then you could actually write a command of the sort that exists on
> other OS's:
>
>    rename *.ada *.adb

rename "*.ada *.adb"

or 

rename "*.ada" "*.adb"

-- 
-- Stephe