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);
}
[download]

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
[download]

while on Solaris 9 or 10, the execname would be more useful

$ ./bar
execname: /home/ck/bin/foo
realpath: /home/ck/bin/foo
[download]

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)