Get actual _full_ name of current executable, not via argv..

>>> Is there any way to get actual _full_ name of current executable,

>> You can try reading the /proc/self/exe-symlink. But a file can
>> have many different names on a filesystem with hard link
>> support, so this may or may not help.

> The executable may also have zero names.

Beginning in Linux 2.6.29, the kernel sets the AT_EXECFN entry of
the ELF auxiliary vector (see /usr/include/elf.h) to the pathname
that was specified to execve(). All Linux 2.x.y kernels put that
pathname into the new address space, but AT_EXECFN documents it.
Most of the time you can also get that pathname via
(1+ strlen(envp[-1+ n_env]) + envp[-1+ n_env])
where envp is the vector of environment variables, and n_env
is their number. Calling putenv(), or otherwise overwriting
the environment vector or environment strings, may invalidate
the expected results.

Independent of how any potential answer is obtained, and independent
of whether the filesystem supports hardlinks, and independent of
whether the potential answer is a rooted or a relative pathname,
there is a race condition. The pathname at the time of execve()
may have designated a different collection of bytes (file) then,
than it does now. It is difficult to prevent such a difference
in all cases. You can come close
if the medium that holds the bytes is physically read-only,
and if the filesystem that holds the bytes is mounted read-only,
and if there are no other mounts of the filesystem that holds the bytes,
and if the mount point, and all its ancestors, also are read-only
and have no conflicting mounts,
and if there are no symbolic links in any of the relevant paths.
That's a lot to ask, and usually it isn't necessary.

One very legitimate use of the pathname is to be the source
for expanding the dynamic string token "$ORIGIN" in DT_RUNPATH,
so that an executable and its associated "private" shared libraries
can be relocated easily in a filesystem. [A Solaris feature copied by
glibc; never documented. glibc trusts readlink("/proc/self/exe",)
in this case.] The AT_EXECFN token also is the perfect place
for a virtualizer program to adjust the environment.

--

On 2009-07-14, Grant Edwards <invalid@invalid> wrote:
> On 2009-07-14, Rainer Weikusat <rweikusat.TakeThisOut@mssgmbh.com> wrote:
>> Alex Vinokur <alexvn.TakeThisOut@users.sourceforge.net> writes:
>
>>> Is there any way to get actual _full_ name of current executable,
>>
>> You can try reading the /proc/self/exe-symlink. But a file can
>> have many different names on a filesystem with hard link
>> support, so this may or may not help.
>
> The executable may also have zero names.

OT: Did you ever wonder why in English the word "zero" is
treated as plural?

"zero names" "one name" "two names" "three names"
^ ^ ^

Is it that way in other languages?

--
Grant Edwards grante Yow! Those people look
at exactly like Donnie and
visi.com Marie Osmond!!

Grant Edwards <invalid@invalid> writes:
>
> OT: Did you ever wonder why in English the word "zero" is
> treated as plural?
>
> "zero names" "one name" "two names" "three names"
> ^ ^ ^
>
> Is it that way in other languages?

I'm not a linguist (nor do I play one on TV), but I'll guess that what's
going on is that the singular is a special case.

We're just taken aback because we expect the special cases to occur at
the boundaries

Alex Vinokur <alexvn RemoveThis @users.sourceforge.net> writes:
> Linux 2.6.18-92.el5
>
> /opt/intel/compiler/bin/intel64/icpc -v
> Version 11.0
>
>
> Is there any way to get actual _full_ name of current executable,

You can try reading the /proc/self/exe-symlink. But a file can have
many different names on a filesystem with hard link support, so this
may or may not help.

Grant Edwards <invalid@invalid> writes:

> On 2009-07-14, Grant Edwards <invalid@invalid> wrote:
>> On 2009-07-14, Rainer Weikusat <rweikusat.RemoveThis@mssgmbh.com> wrote:
>>> Alex Vinokur <alexvn.RemoveThis@users.sourceforge.net> writes:
>>
>>>> Is there any way to get actual _full_ name of current executable,
>>>
>>> You can try reading the /proc/self/exe-symlink. But a file can
>>> have many different names on a filesystem with hard link
>>> support, so this may or may not help.
>>
>> The executable may also have zero names.
>
> OT: Did you ever wonder why in English the word "zero" is
> treated as plural?
>
> "zero names" "one name" "two names" "three names"
> ^ ^ ^
>
> Is it that way in other languages?

It is that way in Swedish.

--
Måns Rullgård
mans.RemoveThis@mansr.com

On Jul 14, 7:40 am, Alex Vinokur <ale....RemoveThis@users.sourceforge.net> wrote:
> Hi,
>
> Linux 2.6.18-92.el5
>
> /opt/intel/compiler/bin/intel64/icpc -v
> Version 11.0
>
> Is there any way to get actual _full_ name of current executable, not
> only via argv[0] in main() program?

The question is incoherent. For example:

If I run '/bin/foo' and then someone does 'mv /bin/foo /bin/bar; mv /
bin/baz /bin/foo' is the "actuall full name of the current executable"
'bin/foo' or '/bin/baz'?

If '/bin/foo' is running and then someone does 'rm /bin/foo', what is
the "actual full name" of the executable?

And so on.

What is your outer problem? The solution is probably not what you
think it is.

DS

On Jul 14, 10:50 pm, David Schwartz <dav....DeleteThis@webmaster.com> wrote:
[snip]
> What is your outer problem? The solution is probably not what you
> think it is.
>
> DS

I need to print full path of executable file to screen/log.

P.S. Answer from other forum:
readlink("/proc/self/exe", buffer, buffer_size);

Alex Vinokur