Trying to use pstat_getpathname when running from DVD

[Ken Englander]

We have a program that is trying to determine where it is being run from. The key piece of the program is below. The problem is the call to pstat_getpathname does not work when the program is executed from a file on a DVD.

Any suggestions would be appreciated! I already looked at three previous threads that come up when I searched for getpathname and it seems this function is not always guaranteed to work depending on what is in the cache.

struct pst_vm_status vmstat;
struct pst_filedetails psfdetails;
char name[1024];
int pid = getpid();

if ((pstat_getprocvm(&vmstat, sizeof(vmstat), pid, 1)) < 0)
return eSysFailure;
if ((pstat_getfiledetails(&psfdetails, sizeof(psfdetails),
&(vmstat.pst_fid))) < 0)
return eSysFailure;
if ((pstat_getpathname(name, sizeof(name), &(vmstat.pst_fid))) <0)
return eSysFailure;

Thanks!

[Dennis Handly · Accepted solution]

I assume you looked at:
http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1278175
http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1280356

Any reason you don't use the tried and true argv[0] solution?

[Ken Englander]

Hi Dennis - The reason why we are not using argv is either because the code was already written before we ported it to HP-UX or simply because that is the way the programmer wrote it.

The code you put in the other thread is probably not an obvious option. NOTE: I did not write this program - I am simply trying to help figure out the fix.

I built the program you provided and it appears what I want is the contents of "argv[0]" - is that right? I am pretty rusty with my C programming skills!

Thanks!

[Dennis Handly]

>The reason why we are not using argv

My statement was about using my argv hand waving instead of newfangled pstat_getpathname(2).

>The code you put in the other thread is probably not an obvious option.

Not obvious in that you can't figure it out, or won't work for you?

>I want is the contents of "argv[0]" - is that right?

It gets the contents of argv[0] and $PATH.
What it doesn't show is how to check argv[0] and then append getcwd(2) or the $PATH components until stat(2) finds an executable.
Something like this:
#include
#include
#include
#include
#include
#include
#include
#include /* _environ, __argv (ELF) */

#if defined(__LP64__) || defined(__ia64)
#define ARGVS __argv
#else
extern char **__argv_value;
#define ARGVS __argv_value
#endif

int main() {
struct stat stat_buf;
char buf[MAXPATHLEN], buf2[MAXPATHLEN];
int i, found;
char *patht, *p;
const char *path = getenv("PATH");

printf("PATH=%s\n", path);
/* Now look at argv[0] and PATH */
if (ARGVS[0][0] == '/') {
printf("Path to executable: %s\n", ARGVS[0]);
return 0;
}
if (!getcwd(buf, sizeof(buf))) {
fprintf(stderr, "Can't get CWD: %s\n", strerror(errno));
return 1;
}
if (ARGVS[0][0] == '.') {
/* Assume it fits */
strcat(buf, "/");
strcat(buf, ARGVS[0]);
printf("Path to executable: %s\n", buf);
return 0;
}
found = 0;
patht = strdup(path);
p = strtok(patht, ":");
while (p) {
if (p[0] == '\0' || strcmp(p, ".") == 0) {
strcpy(buf2, buf);
} else
strcpy(buf2, p);
strcat(buf2, "/");
strcat(buf2, ARGVS[0]);
if (stat(buf2, &stat_buf) == 0 && !(stat_buf.st_mode & S_IFDIR) &&
access(buf2, X_OK) == 0) {
found = 1;
break;
}
p = strtok(NULL, ":");
}
free(patht);
if (found)
printf("Path to executable: %s\n", buf2);
else
printf("Can't find executable path for: %s\n", ARGVS[0]);
return 0;
}

[Ken Englander]

Our coding environment is very controlled. I do not know, but I suspect we are using the same code on AIX. That is, we have common source code, so changes require lots of testing. All of that means, it is easiest if we can continue to use the code that is already written.

I said your solution was not obvious based on my own perspective which is limited since I am not actively writing code and have only done a little C programming.

I have no idea why the program was written as it exists. I am only being asked to help in identifying a solution to the problem.

I opened a case with HP once I had a test program using our technique. It turns out there is a defect in 11.31 that has caused the code to no longer function as expected. So HP will be correcting that problem.

I am going to try the revised code you sent. I'll let you know if that works for a DVD, but it may be several days since I have to build it and write it to a DVD.

Thank you so much for the input.

[Ken Englander]

Dennis - Thanks again for the program - it works fine running from an executable on a DVD. I suspect you already realized the "./" is returned in the output string when the current working directory is used as a reference point. I'm sure I can change that in the code if needed. I did see that HP-UX is perfectly ok with that syntax.

Your input is appreciated!

I guess I should post the HP fix here once I get more information from them?

[Dennis Handly]

>I suspect you already realized the "./" is returned in the output string when the current working directory is used as a reference point.

Did you mean if you use a relative path? If I have "." in PATH, I get the right result. If I execute ./a.out (or any other relative path) I do get: $PWD/./a.out

If you don't like that, you can call realpath(3).

>I guess I should post the HP fix here once I get more information from them?

Sure, you can list the patch ID.