HPUX, aCC (HP ANSI C++ B3910B A.03.27)

I have to determine the path of an executable. I want the same value
as argv[0]. The problem is - my code is a library. I cannot use
argv[0]. I want to use my code in a shared library and (statically
linked) in an executable. Is there a way to determine this path?

Thanks

T.M.

[ Post a follow-up to this message ]

Torsten Mueller <dev-null@shared-files.de> writes:

> HPUX, aCC (HP ANSI C++ B3910B A.03.27)
>
> I have to determine the path of an executable. I want the same value
> as argv[0]. The problem is - my code is a library. I cannot use
> argv[0]. I want to use my code in a shared library and (statically
> linked) in an executable. Is there a way to determine this path?

In general, no.  Why do you need this information?

--
Måns Rullgård
mru@inprovide.com

[ Post a follow-up to this message ]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Torsten Mueller wrote:
> HPUX, aCC (HP ANSI C++ B3910B A.03.27)
>
> I have to determine the path of an executable.

Why? In my experience, when someone says that they have to determine the
path of an executable, they are trying to solve the wrong problem.
Perhaps we can help you solve the right problem.

> I want the same value
> as argv[0].

Which isn't guaranteed to be a path, let alone "the path to the executable".

> The problem is - my code is a library. I cannot use
> argv[0].

And you wouldn't want to, even if you could.

>I want to use my code in a shared library and (statically
> linked) in an executable. Is there a way to determine this path?

Short answer: No, there is no way to determine the path to the executable.

Long answer: Yes, there are several, implementation specific, ways to do
this, but none are guaranteed to be accurate or correct during the
execution lifetime of the process.


- --

Lew Pitcher, IT Specialist, Enterprise Data Systems
Enterprise Technology Solutions, TD Bank Financial Group

(Opinions expressed here are my own, not my employer's)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)

 iD8DBQFCrtaAagVFX4UWr64RAmv9AJ443JwhXW+j
qu1/yUIfSfdNZPkcEgCfaiJB
kPxfh22evmipG4i7VpjcPlA=
=YKwc
-----END PGP SIGNATURE-----

[ Post a follow-up to this message ]

Lew Pitcher <Lew.Pitcher@td.com> schrieb:
 
>
> Why?

(This question seems to be always the first question ...)

> In my experience, when someone says that they have to determine the
> path of an executable, they are trying to solve the wrong problem.
> Perhaps we can help you solve the right problem.

Yeah, it's just to implement the same algorithm that is used under
Windows. I port a software component and it has a config file located
near the executable.

By the while I read somewhere UNIX programmers should use just a fixed
path for config files of an application, /var/opt/PACKAGE or
/usr/local/etc or something like this. I can do this and this would
indeed be a simple solution for the problem. But it's different than
under Windows and then I have to manage such differences. Other people
must know them to avoid confusion.

OK, thanks.

T.M.

[ Post a follow-up to this message ]

Torsten Mueller <dev-null@shared-files.de> writes:

> Lew Pitcher <Lew.Pitcher@td.com> schrieb:
> 
>
> (This question seems to be always the first question ...)
> 
>
> Yeah, it's just to implement the same algorithm that is used under
> Windows. I port a software component and it has a config file located
> near the executable.

Right, that is the wrong problem.

On unix, there may be several users running the same program, and they
won't have all the access rights to read/write the configuration file.
So you should put configuration files in the current user home
directory (or if it's a system-wide tool like a server daemon, in /etc).

#define PNAME  "MyProgram"
char* conf_path=concatenate(getenv("HOME"),"/.",PNAME,".conf",0);

If you will you can either have a #include directive in
~/.MyProgram.conf that would allow each user to include at will a
common configuration file (eg. /etc/MyProgram.defaults), or you can
process the two files:

#define PREFIX "" /* could be "/usr/local" */
#define PNAME  "MyProgram"
char* global_conf_path=concatenate(PREFIX,"/etc/",PNAME,".conf",0);
char*  user_conf_path=concatenate(getenv("HOME"),"/.",PNAME,".conf",0);


> By the while I read somewhere UNIX programmers should use just a fixed
> path for config files of an application, /var/opt/PACKAGE or
> /usr/local/etc or something like this. I can do this and this would
> indeed be a simple solution for the problem. But it's different than
> under Windows and then I have to manage such differences. Other people
> must know them to avoid confusion.

Windows users are rarely unix users, so it won't confuse them to put
configuration files in /etc or in $HOME.  On the other hand, it would
confuse unix administrators and unix user a lot if you did not put
them in /etc or in $HOME.


--
__Pascal Bourguignon__                     http://www.informatimago.com/
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d? s++:++ a+ C+++ UL++++ P--- L+++ E+++ W++ N+++ o-- K- w---
O- M++ V PS PE++ Y++ PGP t+ 5+ X++ R !tv b+++ DI++++ D++
G e+++ h+ r-- z?
------END GEEK CODE BLOCK------

[ Post a follow-up to this message ]

>I have to determine the path of an executable. I want the same value
>as argv[0].

You do know that the value of argv[0] can have absolutely NOTHING
to do with the path to an executable, right?  And if there's any
advantage to be gained by making your program find the WRONG
executable, someone WILL invoke it that way maliciously.

>The problem is - my code is a library. I cannot use
>argv[0]. I want to use my code in a shared library and (statically
>linked) in an executable. Is there a way to determine this path?

What were you planning on using this value for?  Nothing besides
error messages, I hope.  It doesn't sound very secure.

Gordon L. Burditt

[ Post a follow-up to this message ]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Pascal Bourguignon wrote:
> Torsten Mueller <dev-null@shared-files.de> writes:
>
> 
>
>
> Right, that is the wrong problem.
>
> On unix, there may be several users running the same program, and they
> won't have all the access rights to read/write the configuration file.
> So you should put configuration files in the current user home
> directory (or if it's a system-wide tool like a server daemon, in /etc).

To expand on that point a bit,

Per-user configuration should be stored in a file or directory in the
user's home directory

Systemwide configuration and/or configuration defaults, should be stored
in a file or directory in one of the standard configuration directories.

A user-invoked program should use the config file in the home directory,
and perhaps fill in the unspecified values from the system config file.
This might be implemented as

load system config file
load user config file, overriding values of system config file

or it might be implemented as

load user config file
load system config file, discarding values already set by user config

or, it might even be implemented as

if user config exists
load user config file
else
load system config file
fi

- --

Lew Pitcher, IT Specialist, Enterprise Data Systems
Enterprise Technology Solutions, TD Bank Financial Group

(Opinions expressed here are my own, not my employer's)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)

iD8DBQFCrwOHagVFX4UWr64RArpLAKCifXg2l7M//+ZphywTouFCb1vlNACguuO7
UGNuRxwZHD6GkAhL4f7kzwE=
=qKLt
-----END PGP SIGNATURE-----

[ Post a follow-up to this message ]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Gordon Burditt wrote: 
>
>
> You do know that the value of argv[0] can have absolutely NOTHING
> to do with the path to an executable, right?

Perhaps a demonstration for the OP would be in order....

First, a program that echos all it's arguments, including argv[0]
pitchl@srdscs05:~/code/argv0$ cat showargs.c
#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[])
{
int count;

printf("%s Begins\n",__FILE__);
printf("argc == %d\n",argc);
for (count = 0; count < argc; ++count)
printf("argv[%d] == \"%s\"\n",count,argv[count]);
printf("%s Ends\n",__FILE__);

return EXIT_SUCCESS;
}


pitchl@srdscs05:~/code/argv0$ cc -o showargs showargs.c
pitchl@srdscs05:~/code/argv0$ showargs one two 3
showargs.c Begins
argc == 4
argv[0] == "showargs"
argv[1] == "one"
argv[2] == "two"
argv[3] == "3"
showargs.c Ends

As you see, showargs echo's all it's arguments, including argv[0]

Now, let's use exec(3) to run showargs for us.

pitchl@srdscs05:~/code/argv0$ cat arg0.c
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int main(void)
{
execl("./showargs",
"*&&%##/##@$@@\\... this is not my path at all  :-( ",
"an argument",
NULL);

return EXIT_FAILURE;
}
pitchl@srdscs05:~/code/argv0$ cc -o arg0 arg0.c
pitchl@srdscs05:~/code/argv0$ arg0
showargs.c Begins
argc == 2
argv[0] == "*&&%##/##@$@@\... this is not my path at all  :-( "
argv[1] == "an argument"
showargs.c Ends

As you can see, showargs ran, but argv[0] /was not/ the path to the
executable. In fact, argv[0] isn't a path to anything at all. And, this
is perfectly legal in a Unix system.

Now, lets try a variation. No argv[0] at all...

pitchl@srdscs05:~/code/argv0$ cat noargs.c
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int main(void)
{
execl("./showargs",
NULL);

return EXIT_FAILURE;
}
pitchl@srdscs05:~/code/argv0$ cc -o noargs noargs.c
pitchl@srdscs05:~/code/argv0$ noargs
showargs.c Begins
argc == 0
showargs.c Ends
pitchl@srdscs05:~/code/argv0$

Here, showargs ran, but it didn't even get garbage as argv[0]. Instead,
it got nothing at all, no arg[0] whatsoever. Again, perfectly legal in
Unix, but bad breakage for a program that thinks that MSWindows rules apply.


- --

Lew Pitcher, IT Specialist, Enterprise Data Systems
Enterprise Technology Solutions, TD Bank Financial Group

(Opinions expressed here are my own, not my employer's)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)

 iD8DBQFCrwisagVFX4UWr64RAncqAKCaxtXPVUnz
5NZHa8uM1j21NrvNTQCg7Hq8
/h6V9p+SEne5KODio3nb39U=
=Oyii
-----END PGP SIGNATURE-----

[ Post a follow-up to this message ]

"Torsten Mueller" <dev-null@shared-files.de> wrote in message
news:uoea9vwb2.fsf@fastmail.fm...
> Lew Pitcher <Lew.Pitcher@td.com> schrieb:
> 
>
> (This question seems to be always the first question ...)
> 
>
> Yeah, it's just to implement the same algorithm that is used under
> Windows. I port a software component and it has a config file located
> near the executable.
>
> By the while I read somewhere UNIX programmers should use just a fixed
> path for config files of an application, /var/opt/PACKAGE or
> /usr/local/etc or something like this. I can do this and this would
> indeed be a simple solution for the problem. But it's different than
> under Windows and then I have to manage such differences. Other people
> must know them to avoid confusion.
>
> OK, thanks.
>
> T.M.

Encapsulate the differences. I have "ConfigSettings" library code that
supports global and local settings. Local setting are per user. On Windows
the code uses the registry and uses current user for local and current
machine for global. On Unix systems the settings are saved in text files.
Local settings are in a hidden directory in the users home directory and
global settings are in /opt. The config settings take a company name as a
parameter. On Windows this is the registry directory and on unix a file
directory. For example the Unix global setting directory would be
/opt/Saperion. The Unix local directory would be $HOME/.Saperion/.

Norman
Saperion Inc.

[ Post a follow-up to this message ]

TJB replied to:

> In general, no.  Why do you need this information?

I'm -shocked- that this answer is no.

In Windows land you would use this to figure where your installation
directory is.  At start up I do something like this:

void layout_window_type::cd_to_self()
{
wchar_t buffer[ 16384 ];
GetModuleFileName( NULL,  buffer,	DIM(buffer) );
wchar_t *last_slash, *p;

last_slash = buffer;
p = buffer;

while (*p) {
p++;

if (*p == '\') {
last_slash = p;
}
}

if (*last_slash == '\') {
*last_slash = 0;
SetCurrentDirectory( buffer );
}
}

Then, I can hang configuration information off of the application's
directory  So, regardless of the current directory of an application,
it can find its own root directory.  Then, you can have configuration
stuff inside of that directory, and you don't need the registry any
more.

[ Post a follow-up to this message ]