Re: How to get the application path
- From: Adam Beneschan <adam@xxxxxxxxxx>
- Date: Tue, 24 Jul 2007 07:55:00 -0700
On Jul 24, 4:11 am, Stephen Leake <stephen_le...@xxxxxxxxxxxxxxxx>
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
.
- Follow-Ups:
- Re: How to get the application path
- From: Markus E Leypold
- Re: How to get the application path
- References:
- How to get the application path
- From: Rangdalf
- Re: How to get the application path
- From: Stephen Leake
- Re: How to get the application path
- From: Adam Beneschan
- Re: How to get the application path
- From: Stephen Leake
- How to get the application path
- Prev by Date: Re: How to get the application path
- Next by Date: Re: How to get the application path
- Previous by thread: Re: How to get the application path
- Next by thread: Re: How to get the application path
- Index(es):
Relevant Pages
|