Unfortunately, the box is solaris 8, not 10 ...
I was afraid you were going to say that :) — in this case
you're essentially out of luck...
On anything older than Solaris 10, the proc filesystem is rather
limited.
AFAIK, the only info remotely similar to /proc/self/exe (or /proc/self/path/a.out for that matter), is
in /proc/self/auxv (aux vector — a binary structure),
but it's not really the same, in particular on Solaris 8 (things have
gotten somewhat better starting with Solaris 9).
If you're really determined, you could try to hack up something
based on the standard C library functions getexecname, which
extracts the appropriate structure from /proc/self/auxv, together
with realpath, which resolves all "..", "." and symbolic links
in a path (, and possibly also getcwd).
One ugly problem with getexecname on Solaris 8 is that it
doesn't make a distinction between an executable script and its associated
interpreter invoked via the shebang line. For example, with the
following naive snippet
#include <stdlib.h>
#include <limits.h>
#include <stdio.h>
int main() {
const char *execname;
char *execpath;
char pathbuf[PATH_MAX];
execname = getexecname();
execpath = realpath(execname, pathbuf);
printf("execname: %s\n", execname);
printf("realpath: %s\n", execpath);
}
if you compile this with cc foo.c -o foo and put the
resulting binary in - let's say - /home/ck/bin/, and then create a
dummy script bar with the shebang line #!/home/ck/bin/foo in
some other directory like /home/ck/myscripts/, and call it from there,
you'd get on Solaris 8:
$ ./bar
execname: bar
realpath: /home/ck/myscripts/bar
while on Solaris 9 or 10, the execname would be more useful
$ ./bar
execname: /home/ck/bin/foo
realpath: /home/ck/bin/foo
You see the problem with Solaris 8 — and this is not the only one...
(note that the code would of course have to be linked into perl (to set $^X),
i.e. the foo in the example represents the Perl binary)
|