How to get the application path

How to get the application path

[Rangdalf]

Hi,

In C# there is something like Application.startupPath. Is there a 
package or function to get this path.
I can get the current directory but I need the application one.

Regards

Re: How to get the application path

[qouify]

On 23 juil, 09:20, Rangdalf <rangd...@hotmail.com> wrote:
> Hi,
>
> In C# there is something like Application.startupPath. Is there a
> package or function to get this path.
> I can get the current directory but I need the application one.
>
> Regards

Hi,
the gnat provides the function Locate_Exec_On_Path.
you can locate the path of an application if it is in the path
environment variable by doing this

with gnat.os_lib;
...
A : String_Access := Locate_Exec_On_Path("gcc");
begin
if A = Null then
Put_Line("gcc not found in your PATH");
else
...

Re: How to get the application path

[Stephen Leake]

Rangdalf <rangdalf@hotmail.com> writes:

> Hi,
>
> In C# there is something like Application.startupPath. Is there a
> package or function to get this path.
> I can get the current directory but I need the application one.

In Ada 95, Ada.Command_Line.Command_Name returns the executable name,
which usually (not always) has the full path; that is the application
path.

There may be a better solution in Ada 2005.

-- 
-- Stephe

Re: How to get the application path

[Adam Beneschan]

On Jul 23, 5:34 am, Stephen Leake <stephen_le...@stephe-leake.org>
wrote:
> Rangdalf <rangd...@hotmail.com> writes:
> > Hi,
>
> > In C# there is something like Application.startupPath. Is there a
> > package or function to get this path.
> > I can get the current directory but I need the application one.
>
> In Ada 95, Ada.Command_Line.Command_Name returns the executable name,
> which usually (not always) has the full path

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

Maybe things are different on Windows, but the original poster didn't
refer to any particular operating system.

; 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.  To extract just the directory
name, without the base name, Ada.Directories.Containing_Directory
(Ada.Directories.Full_Name (Ada.Command_Line.Command_Name)) should
work.

                      -- Adam

Re: How to get the application path

[Markus E Leypold]

> On Jul 23, 5:34 am, Stephen Leake <stephen_le...@stephe-leake.org>
> wrote:
>> Rangdalf <rangd...@hotmail.com> writes:
>> > Hi,
>>
>> > In C# there is something like Application.startupPath. Is there a
>> > package or function to get this path.
>> > I can get the current directory but I need the application one.
>>
>> In Ada 95, Ada.Command_Line.Command_Name returns the executable name,
>> which usually (not always) has the full path
>
> 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).
>
> Maybe things are different on Windows, but the original poster didn't
> refer to any particular operating system.
>
> ; 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

Command_Name returns the first element of argv[]. There is a
convention that this is the name of the executable. But since argv[0]
is set by the invoking process, it might be anything: The full path of
an executable, just the executable name (which it usually is on Unix
with the Bourne shell when path searching is in effect) or _anything_
else.

BTW: Is it possible the OP doesn't want the path to the executable,
but rather the directory which becomes /became the wurrent directory
of the application at startup? Isn't that what Application.startupPath
is on Windows?


> 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.  To extract just the directory
> name, without the base name, Ada.Directories.Containing_Directory
> (Ada.Directories.Full_Name (Ada.Command_Line.Command_Name)) should
> work.


Regards -- Markus

Re: How to get the application path

[Dmitry A. Kazakov]

On Mon, 23 Jul 2007 08:27:39 -0700, Adam Beneschan 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).
> 
> Maybe things are different on Windows, but the original poster didn't
> refer to any particular operating system.

AFAIK Windows indeed places the module name into argv[0] rather than the
first token of the command line (the module name is what GetModuleFileName
API would return). The original command line can still be obtained via
GetCommandLine.

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

Re: How to get the application path

[Georg Bauhaus]

On Mon, 2007-07-23 at 09:20 +0200, Rangdalf wrote:
> Hi,
> 
> In C# there is something like Application.startupPath. Is there a 
> package or function to get this path.
> I can get the current directory but I need the application one.

If you are programming in the .NET environment,
call Application.startupPath (with A#).

Re: How to get the application path

[Stephen Leake]

Adam Beneschan <adam@irvine.com> writes:

> On Jul 23, 5:34 am, Stephen Leake <stephen_le...@stephe-leake.org>
> wrote:
>> Rangdalf <rangd...@hotmail.com> writes:
>> > Hi,
>>
>> > In C# there is something like Application.startupPath. Is there a
>> > package or function to get this path.
>> > I can get the current directory but I need the application one.
>>
>> In Ada 95, Ada.Command_Line.Command_Name returns the executable name,
>> which usually (not always) has the full path
>
> 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.

> ; 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, 

Yes, this is the right solution.

> 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". LRM A.16 (47) defines
"full name" as you would expect, with no reference to "default directory".

I'll update my code to use this, so it is more robust.

-- 
-- Stephe

Re: How to get the application path

[Stephen Leake]

Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes:

> BTW: Is it possible the OP doesn't want the path to the executable,
> but rather the directory which becomes /became the wurrent directory
> of the application at startup? Isn't that what Application.startupPath
> is on Windows?

Right. In which case Ada.Directories.Current_Directory is the answer.

If you want the default directory at the start of the application,
call this then, and cache it. If you want the default directory at the
time of whatever operation you are currently doing, call it then.

-- 
-- Stephe

Re: How to get the application path

[Markus E Leypold]

> Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes:
>
>> BTW: Is it possible the OP doesn't want the path to the executable,
>> but rather the directory which becomes /became the wurrent directory
>> of the application at startup? Isn't that what Application.startupPath
>> is on Windows?
>
> Right. In which case Ada.Directories.Current_Directory is the answer.

Yeah, but you have to get it once during application startup.

> If you want the default directory at the start of the application,
> call this then, and cache it. 

:-) 

> If you want the default directory at the time of whatever operation
> you are currently doing, call it then.

Regards -- Markus

Re: How to get the application path

[Niklas Holsti]

Stephen Leake wrote:
> Adam Beneschan <adam@irvine.com> writes:
> 
> 
>>On Jul 23, 5:34 am, Stephen Leake <stephen_le...@stephe-leake.org>
>>wrote:
>>
>>>Rangdalf <rangd...@hotmail.com> writes:
>>>
>>>>Hi,
>>>
>>>>In C# there is something like Application.startupPath. Is there a
>>>>package or function to get this path.
>>>>I can get the current directory but I need the application one.
>>>
>>>In Ada 95, Ada.Command_Line.Command_Name returns the executable name,
>>>which usually (not always) has the full path
...
>>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, 
> 
> 
> Yes, this is the right solution.

I hardly think so. As I understand it, Full_Name is meant to expand 
simple file names like "file.txt" and relative file-names like 
"../../foo/file.txt" into full names by using the default directory and 
expanding "abbreviations" (A.16 (47)).

If the Command_Name is simply "bong.exe", you cannot expect Full_Name to 
search through the file system to find the directory that contains 
"bong.exe". There could be several such directories. Full_Name cannot 
use the PATH envinroment variable to find the directory because PATH 
only applies to executable files and Full_Name should apply to all files.

If Command_Name gives you only the simple name, and you want the full 
name, I think you must use Ada.Environment_Variables to get the value of 
PATH and then scan the PATH directories for the Command_Name. But then 
it would be simpler to just put the "application path" into a well-named 
environment variable and forget about Command_Name.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: How to get the application path

[Robert A Duff]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> Adam Beneschan <adam@irvine.com> writes:
>> 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, 
>
> Yes, this is the right solution.

I don't think Full_Name is what you want.

If you are in /home/myself, and you type foo on the command line, and it
finds /usr/bin/foo (using your path) and runs it, and Command_Name = "foo",
then calling Full_Name will give you /home/myself/foo, not
/usr/bin/foo.

I think there ought to be a simple way for a process to find its
executable file name that is guaranteed to work.  Since there isn't,
I guess you have to search the path (duplicating what the shell
already did).

These days, some folks will say, "What's a path?  What's a command
line?"  ;-)

- Bob

Re: How to get the application path

[Adam Beneschan]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 2429 bytes --]

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

Re: How to get the application path

[Adam Beneschan]

On Jul 24, 7:07 am, Robert A Duff <bobd...@shell01.TheWorld.com>
wrote:
> Stephen Leake <stephen_le...@stephe-leake.org> writes:
> > Adam Beneschan <a...@irvine.com> writes:
> >> 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,
>
> > Yes, this is the right solution.
>
> I don't think Full_Name is what you want.
>
> If you are in /home/myself, and you type foo on the command line, and it
> finds /usr/bin/foo (using your path) and runs it, and Command_Name = "foo",
> then calling Full_Name will give you /home/myself/foo, not
> /usr/bin/foo.

Yes, I forgot about that.

                        -- Adam

Re: How to get the application path

[Markus E Leypold]

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

I think thepoint is not that the OP wants icons. The problem is to
find the application's installation directory (where all other
spplication data is, often including configuration) when the
application has been started from e.g. a windows desktop.

Regards -- Markus

Re: How to get the application path

[Randy Brukardt]

"Niklas Holsti" <niklas.holsti@nospam.please> wrote in message
news:46a5e4e1$0$27850$39db0f71@news.song.fi...
...
> If the Command_Name is simply "bong.exe", you cannot expect Full_Name to
> search through the file system to find the directory that contains
> "bong.exe". There could be several such directories. Full_Name cannot
> use the PATH envinroment variable to find the directory because PATH
> only applies to executable files and Full_Name should apply to all files.

Well, on Janus/Ada the Path applies to all files (Open searches the path if
given a simple file name). This cames from inadequate DOS documentation when
we were building our compiler in the early 1980's, and an unwillingness to
break existing code.

Anyway, in Janus/Ada 95, all you do is open "Bong.Exe" and then ask for the
Name; that will definitely find the file and return its full path. Not sure
whether the Amendment updates will change that (probably not, it would break
all of our code...).

> If Command_Name gives you only the simple name, and you want the full
> name, I think you must use Ada.Environment_Variables to get the value of
> PATH and then scan the PATH directories for the Command_Name. But then
> it would be simpler to just put the "application path" into a well-named
> environment variable and forget about Command_Name.

Yes, that's how you'd have to do it in general. Yuck. (At least you can do
that with Ada.Directories.) I don't see how an Ada program could put the
application path into an environment variable, though; this is the sort of
thing that I wouldn't want to have to go outside of Ada to do (because it
would depend on the user "doing the right thing", and we all know that users
often don't do the right thing).

                         Randy.

Re: How to get the application path

[Niklas Holsti]

Randy Brukardt wrote:
> "Niklas Holsti" <niklas.holsti@nospam.please> wrote in message
> news:46a5e4e1$0$27850$39db0f71@news.song.fi...
> ...

>>If Command_Name gives you only the simple name, and you want the full
>>name, I think you must use Ada.Environment_Variables to get the value of
>>PATH and then scan the PATH directories for the Command_Name. But then
>>it would be simpler to just put the "application path" into a well-named
>>environment variable and forget about Command_Name.
> 
> 
> Yes, that's how you'd have to do it in general. Yuck. (At least you can do
> that with Ada.Directories.) I don't see how an Ada program could put the
> application path into an environment variable, though; this is the sort of
> thing that I wouldn't want to have to go outside of Ada to do (because it
> would depend on the user "doing the right thing", and we all know that users
> often don't do the right thing).

I had in mind that the application installer tool would set up the 
environment variable somehow (system-dependent no doubt). Indeed users 
should not be troubled with that.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: How to get the application path

[Markus E Leypold]

> "Niklas Holsti" <niklas.holsti@nospam.please> wrote in message
> news:46a5e4e1$0$27850$39db0f71@news.song.fi...
> ...
>> If the Command_Name is simply "bong.exe", you cannot expect Full_Name to
>> search through the file system to find the directory that contains
>> "bong.exe". There could be several such directories. Full_Name cannot
>> use the PATH envinroment variable to find the directory because PATH
>> only applies to executable files and Full_Name should apply to all files.
>
> Well, on Janus/Ada the Path applies to all files (Open searches the path if
> given a simple file name). This cames from inadequate DOS documentation when
> we were building our compiler in the early 1980's, and an unwillingness to
> break existing code.
>
> Anyway, in Janus/Ada 95, all you do is open "Bong.Exe" and then ask for the
> Name; that will definitely find the file and return its full path. Not sure
> whether the Amendment updates will change that (probably not, it would break
> all of our code...).
>
>> If Command_Name gives you only the simple name, and you want the full
>> name, I think you must use Ada.Environment_Variables to get the value of
>> PATH and then scan the PATH directories for the Command_Name. But then
>> it would be simpler to just put the "application path" into a well-named
>> environment variable and forget about Command_Name.
>
> Yes, that's how you'd have to do it in general. Yuck. (At least you can do
> that with Ada.Directories.) I don't see how an Ada program could put the
> application path into an environment variable, though; this is the sort of
> thing that I wouldn't want to have to go outside of Ada to do (because it
> would depend on the user "doing the right thing", and we all know that users
> often don't do the right thing).

Now, on Unix I'd just put a shell script wrapper in place of the executable:

   MYPATH="$0"
   MYAPP="$(which $MYPATH.bin)"  # locate the executable proper

   export EXE_PATH="$MYPATH"

   exec $MYAPP "$@"

(untested, mind you).

That would even put the full path in argv[0]. The power of shell
script wrappers in Unix is usually underestimated.

Regards -- Markus





>
>                          Randy.

Re: How to get the application path

[Markus E Leypold]

> Randy Brukardt wrote:
>> "Niklas Holsti" <niklas.holsti@nospam.please> wrote in message
>> news:46a5e4e1$0$27850$39db0f71@news.song.fi...
>> ...
>
>>>If Command_Name gives you only the simple name, and you want the full
>>>name, I think you must use Ada.Environment_Variables to get the value of
>>>PATH and then scan the PATH directories for the Command_Name. But then
>>>it would be simpler to just put the "application path" into a well-named
>>>environment variable and forget about Command_Name.
>> Yes, that's how you'd have to do it in general. Yuck. (At least you
>> can do
>> that with Ada.Directories.) I don't see how an Ada program could put the
>> application path into an environment variable, though; this is the sort of
>> thing that I wouldn't want to have to go outside of Ada to do (because it
>> would depend on the user "doing the right thing", and we all know that users
>> often don't do the right thing).
>
> I had in mind that the application installer tool would set up the
> environment variable somehow (system-dependent no doubt). Indeed users
> should not be troubled with that.


In Unix a shell script wrapper can set the environment variable. In
Windows there is a way to set the startup path in the registry, this
becomes the current directory when the application is started from the
desktop ("by icon"). Make that path be the place where you install all
files belonging to the application (maybe also including a app.ini
file which has the location of other relocatable parts of the
installation and will be generated at install time. 

Now you can record the current directory at app startup as
installation directory and read the rest of the paths from
$installationdirectory/app.ini when needed.

Mission accomplished.

Regards -- Markus

Re: How to get the application path

[Stephen Leake]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:

> Stephen Leake <stephen_leake@stephe-leake.org> writes:
>
>> Adam Beneschan <adam@irvine.com> writes:
>>> 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, 
>>
>> Yes, this is the right solution.
>
> I don't think Full_Name is what you want.
>
> If you are in /home/myself, and you type foo on the command line, and it
> finds /usr/bin/foo (using your path) and runs it, and Command_Name = "foo",
> then calling Full_Name will give you /home/myself/foo, not
> /usr/bin/foo.

Hmm. It seems I missed A.16 (48):

48/2
    The default directory is the directory that is used if a directory or
    file name is not a full name (that is, when the name does not fully
    identify all of the containing directories).

-- 
-- Stephe

Re: How to get the application path

[Randy Brukardt]

"Markus E Leypold"
<development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> wrote in
message news:5lr6mx6c7b.fsf@hod.lan.m-e-leypold.de...
>
> > 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.
>
> I think thepoint is not that the OP wants icons. The problem is to
> find the application's installation directory (where all other
> spplication data is, often including configuration) when the
> application has been started from e.g. a windows desktop.

On Windows, you need to find that in the registry. The application path for
configuration purposes is not necessarily the same as the path that it was
launched from.

Claw has a bunch of routines for setting and retriving the application path
in the Claw.Registry.Shell package.

Another way to say this is that it can't be done portably, at least if you
are going to follow the OS "standards" for such things. Otherwise, you
should just do it yourself and not worry about what the OS thinks.

                             Randy.

Re: How to get the application path

[Stephen Leake]

Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes:

> Now, on Unix I'd just put a shell script wrapper in place of the executable:

Why do you limit this to "Unix"? Any operating system that supports
shells can do the same thing. 

>    MYPATH="$0"
>    MYAPP="$(which $MYPATH.bin)"  # locate the executable proper
>
>    export EXE_PATH="$MYPATH"
>
>    exec $MYAPP "$@"
>
> (untested, mind you).
>
> That would even put the full path in argv[0]. The power of shell
> script wrappers in Unix is usually underestimated.

Scratch the "in Unix", and I agree.

A Windows icon can launch a cmd shell wrapper. Or a Cygwin bash
wrapper, for that matter!

-- 
-- Stephe

Re: How to get the application path

[Markus E.L.]

> Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes:
>
>> Now, on Unix I'd just put a shell script wrapper in place of the executable:
>
> Why do you limit this to "Unix"? Any operating system that supports
> shells can do the same thing. 

Yes+No. In Unix I can just exec the real binary, so I don't have a
shell process waiting until the the binary proper returns. In Windows
the shell process will (AFAI understand it) exist until the
application terminates and AFAIS (worse) it will even have a command
line window open to the absolute irritation of the lay user. 

If I do the right things (use start.exe, for once) the shell window
will open only shortly, but will still irritate the user.

I find the Unix way more palatable.

>>    MYPATH="$0"
>>    MYAPP="$(which $MYPATH.bin)"  # locate the executable proper
>>
>>    export EXE_PATH="$MYPATH"
>>
>>    exec $MYAPP "$@"
>>
>> (untested, mind you).
>>
>> That would even put the full path in argv[0]. The power of shell
>> script wrappers in Unix is usually underestimated.
>
> Scratch the "in Unix", and I agree.

Could you tell me the equivalent of my script in CMD.exe? (Seriously,
that's a real question: What I got until now I consider kludgy).

> A Windows icon can launch a cmd shell wrapper. Or a Cygwin bash
> wrapper, for that matter!

Yes, but cygwin has problems of its own (security for once, it's
rather intrusive), so it's not OK in my opinion to run it at end user
machines (at least w/o much further research to be done which is a bit
difficult given the general attitude ("BWAM") at the cygwin mailing
lists :-(.)


Regards -- Markus

Re: How to get the application path

[Randy Brukardt]

"Markus E.L." <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de>
wrote in message news:o6vec14g46.fsf@hod.lan.m-e-leypold.de...
>
> > Markus E Leypold
<development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes:
> >
> >> Now, on Unix I'd just put a shell script wrapper in place of the
executable:
> >
> > Why do you limit this to "Unix"? Any operating system that supports
> > shells can do the same thing.
>
> Yes+No. In Unix I can just exec the real binary, so I don't have a
> shell process waiting until the the binary proper returns. In Windows
> the shell process will (AFAI understand it) exist until the
> application terminates and AFAIS (worse) it will even have a command
> line window open to the absolute irritation of the lay user.

That doesn't have to be the case, although getting rid of it requires yet
another program. (Essentially, you redirect the output to null, although
doing that specifically doesn't work. It took me several days of
trial-and-error to get that to work,  and it's not certain to me what I did
specifically that made it work. So I have my doubts that it would work with
another compiler, so I'm not going to share the details [Janus/Ada users can
ask, of course].)

...
> I find the Unix way more palatable.
>
> >>    MYPATH="$0"
> >>    MYAPP="$(which $MYPATH.bin)"  # locate the executable proper
> >>
> >>    export EXE_PATH="$MYPATH"
> >>
> >>    exec $MYAPP "$@"
> >>
> >> (untested, mind you).
> >>
> >> That would even put the full path in argv[0]. The power of shell
> >> script wrappers in Unix is usually underestimated.
> >
> > Scratch the "in Unix", and I agree.
>
> Could you tell me the equivalent of my script in CMD.exe? (Seriously,
> that's a real question: What I got until now I consider kludgy).

Application paths in Windows are supposed to be set in the registry; "Path"
is supposedly obsolete. (Yes, hardly anybody actually follows that
documentation.) As such, you're supposed to put the path into the icon or
(as we do) directly into the script [we have the installer create the
appropriate scripts for the user's machine]. Meaning there is no need for
such fancy scripts.

If I actually had to do this, I'd simply write a Janus/Ada program to do it
(remember that all opens search the path in Janus/Ada, so getting the path
is just a matter of text processing the name). Ada is usually better than
silly scripts anyway. [Although these days I'd put the path into the
registry and use the Claw interface I mentioned last week to retrieve it.]

Moral: trying to make Windows work like Unix necessarily makes tasks harder
than they need to be. (The converse is also true, of course.) Very much like
using Ada as if it is C.

                               Randy.

Re: How to get the application path

[Markus E.L. 2]

"Randy Brukardt" wrote:

> "Markus E.L." <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de>
> wrote in message news:o6vec14g46.fsf@hod.lan.m-e-leypold.de...
>>
>> > Markus E Leypold
> <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes:
>> >
>> >> Now, on Unix I'd just put a shell script wrapper in place of the
> executable:
>> >
>> > Why do you limit this to "Unix"? Any operating system that supports
>> > shells can do the same thing.
>>
>> Yes+No. In Unix I can just exec the real binary, so I don't have a
>> shell process waiting until the the binary proper returns. In Windows
>> the shell process will (AFAI understand it) exist until the
>> application terminates and AFAIS (worse) it will even have a command
>> line window open to the absolute irritation of the lay user.

> That doesn't have to be the case, although getting rid of it requires yet
> another program. (Essentially, you redirect the output to null, although
> doing that specifically doesn't work. It took me several days of
> trial-and-error to get that to work,  and it's not certain to me what I did
> specifically that made it work. 

A pity. :-). I think I have some glimmering how that could be done,
but never actually tried it out (Hint: Openssh in Cygwin must do a
similar redirection, because one can run a CMD.exe in a Cygwin
session).

> So I have my doubts that it would work with
> another compiler, so I'm not going to share the details [Janus/Ada users can
> ask, of course].)
>


>> I find the Unix way more palatable.
>>
>> >>    MYPATH="$0"
>> >>    MYAPP="$(which $MYPATH.bin)"  # locate the executable proper
>> >>
>> >>    export EXE_PATH="$MYPATH"
>> >>
>> >>    exec $MYAPP "$@"
>> >>
>> >> (untested, mind you).
>> >>
>> >> That would even put the full path in argv[0]. The power of shell
>> >> script wrappers in Unix is usually underestimated.
>> >
>> > Scratch the "in Unix", and I agree.
>>
>> Could you tell me the equivalent of my script in CMD.exe? (Seriously,
>> that's a real question: What I got until now I consider kludgy).
>
> Application paths in Windows are supposed to be set in the registry; "Path"
> is supposedly obsolete. 

As I understand it, the application is started with the application
path in the registry as current directory. That's how I store the
installation location in the registry (during installation) and how I
retrieve it: I can be sure the application "wakes up" in its own
directory and the rest is there in application specific configuration
files (I could use the registry more, but in most cases I like the
option to edit text based config files).

But my question wasn't this: My questions was: Instead of the
application I want to run a shell script wrpper (e.g. from the start
menu) and the start the application. Now I have 2 problems

 (a) Need to get rid of the command line window, can't have that.

 (b) Need to find out where the script is located from within the
     script (because that is also the place where the application
     binary will be).

It seems, you can't do that in Windows as easily as you can in Unix.


> (Yes, hardly anybody actually follows that
> documentation.) As such, you're supposed to put the path into the icon or
> (as we do) directly into the script [we have the installer create the
> appropriate scripts for the user's machine]. Meaning there is no need for
> such fancy scripts.

Yes, there is something in this. Actually I also resorted to that
solution at another time (but never really solved (a)).

> If I actually had to do this, I'd simply write a Janus/Ada program to do it
> (remember that all opens search the path in Janus/Ada, so getting the path
> is just a matter of text processing the name). 

Not really. The binary application I'm talking about is not in the
path (it should not, since I don't want to touch PATH)

[Hm, I just know begin to understand what you mean by ApplicationPath:
Application specific path variable?]

> Ada is usually better than silly scripts anyway.

Admitted. But you can't generate them at installation time. And at the
very beginning (when the application starts) I can't find where the
application is, so can't read it from the configuration files.


> [Although these days I'd put the path into the registry and use the
> Claw interface I mentioned last week to retrieve it.]

Another solution :-). I originally tried to avoid it for various
reasons (specifically avoiding platform specific parts in the program
and wanting to make backup and restore of the software installation
simple).

> Moral: trying to make Windows work like Unix necessarily makes tasks harder
> than they need to be. 

I never doubted that. :-). Indeed I already admitted that. I 
quoted the shell script because SL wrote:

| > > Why do you limit this to "Unix"? Any operating system that
| > > supports shells can do the same thing.

and I had my doubts about that (which you basically confirmed).


> (The converse is also true, of course.) Very much like
> using Ada as if it is C.

Regards -- Markus