On Jul 24, 4:11 am, Stephen Leake <stephen_le...@stephe-leake.org>
wrote:

> > I really have to question this.  I tried it using GNAT on Linux, and
> > (as I expected) Command_Name simply returns whatever was the first
> > token I entered on the shell command line---i.e. argv[0] (which is
> > what the Ada 95 manual hints that Command_Name should return).
>
> Yes, that is exactly what it does.
>
> I guess in the cases I use it, I always launch a program by specifying
> its full path.
>
> That is typically the case for launching from an icon, for example.

What's an icon? :) :)

Seriously, I'm enougb of a dinosaur that I still use command lines for
everything, most of the time.  (Even on Windows.)  I still think it's
the coolest thing that I don't have to punch my commands onto
Hollerith cards any more.


> > ; that is the application
> >> path.
>
> >> There may be a better solution in Ada 2005.
>
> > If we assume that Command_Name returns the name of some (executable)
> > file that may or may not be a full path name, then
> > Ada.Directories.Full_Name (Ada.Command_Line.Command_Name) should
> > return the full path,

> > if the default directory hasn't been changed with
> > Ada.Directories.Set_Directory.
>
> Why should this depend on the "default directory"? LRM A.16 (71) says
> Full_Name returns "the full name of the file"

AARM A.16 (72.a): "Full name means that no abbreviations are used in
the returned name, and that it is a full specification of the name.
Thus, for Unix and Windows®, the result should be a full path that
does not contain any "." or ".." directories. Typically, the default
directory is used to fill in any missing information."

Niklas already answered this.  If you give it a simple file name, the
only reasonable way it can expand this into a full file name is by
using the current (default) directory, since the simple file name is a
string that doesn't carry any magic dust that tells it what directory
the string refers to.


> . LRM A.16 (47) defines
> "full name" as you would expect, with no reference to "default directory".

It defines what the "full name" of an *external* *file* is, but that
isn't enough to define what the "full name corresponding to a file
*name*" [emphasis mine] is (A.16(72)), since a file name does not
necessarily uniquely identify an external file.

                       -- Adam