[tex-k] kpse program name

[Joachim Schrod]

>>>>> "AK" == Akira Kakuto <kakuto at fsci.fuk.kindai.ac.jp> writes:
>> kpse_set_program_name("dvilj", NULL);

>> in a main program, it doesn't take "dvilj" as program name.
>> 
>> "Doesn't take"?
>> 
>> kpse_set_program_name(), one expects that it *does* set the program
>> name and not that it ignores the argument.
>> 
>> Can you propose a patch?  I'm not sure what you were expecting.

AK> I think that Olaf introduced the second argument for
AK> kpse_set_program_name() in order to set kpse_program_name
AK> "defferent from program_invocation_short_name".
AK> So, the right usage in this case is

AK> kpse_set_program_name (argv[0], "dvilj");

Yes, and I originally proposed that it is made more explicit in the
kpathsea documentation that argv[0] as the 1st argument is *mandatory*
and *must not* be replaced by another program name. That implicitely
means that one also emphasizes that kpse_set_progname() is not merely
depreciated, but that one *must* use argv[0] there, too.

I am willing to propose changes to the kpathsea documentation to that
effect.

But now it seems to me that we should clarify first if that is really
the intended behavior. Let me explain my irritation with a very small
example program:

    #include <kpathsea/kpathsea.h>

    int main (int argc, char * argv)
    {
	string auto_loc;
	/* directory or file in the 1st argument may not exist... */
	kpse_set_program_name("/shared/texlive/bin/dvilj", NULL);
	auto_loc = kpse_var_value("SELFAUTOLOC");
	printf ("SELFAUTOLOC: %s\n", auto_loc);
	exit (0);
    }

Compile this on Linux and run it. You get:

    puma:kpathsea $ uname -a
    Linux puma 2.6.13-15.16-smp #1 SMP Fri Jun 8 15:35:39 UTC 2007 i686 i686 i386 GNU/Linux
    puma:kpathsea $ gcc -I.. try.c -o try -L .libs -lkpathsea
    puma:kpathsea $ ./try 
    SELFAUTOLOC: /shared/home/schrod/src/texlive.linux/texk/kpathsea

That's because Linux ignores the 1st argument to
kpse_set_program_name() and uses GNU libc's notion how the program is
named.

Compile this on Solaris and run it, on a system where the directory
or the file of the 1st argument does not exist. You get:

    baghira:kpathsea $ uname -a
    SunOS baghira 5.10 Generic_118833-36 sun4u sparc SUNW,Sun-Blade-100
    baghira:kpathsea $ gcc -I.. try.c -o try -L .libs -lkpathsea
    baghira:kpathsea $ ./try 
    lstat(/shared/texlive/bin) failed ...
    /shared/texlive/bin: No such file or directory
    Segmentation Fault (core dumped)

Well, now create this directory and file, then try again. You get:

    baghira:kpathsea $ mkdir /shared/texlive/bin
    baghira:kpathsea $ touch /shared/texlive/bin/dvilj
    baghira:kpathsea $ ./try 
    SELFAUTOLOC: /shared/texlive/bin

We can observe two things:

 1) The behavior of passing an argument that is not argv[0] to
    kpse_set_program_name() is not well defined; it differs between
    Linux and Solaris. (In fact, it differs between systems with and
    without GNU libc.)

 2) If one passes an argument that is not argv[0] on a system without
    GNU libc, the program might abort with a core dump, instead of
    terminating gracefully.

And thus, before I propose a specific documentation update, I would
like to know if these two observations are really meant to be the
intended semantics of kpse_set_program_name(). If yes, I propose
documentation changes. If not, we might want to look for patches to
the behaviour of that function. (I don't expect it to be a pure yes-no
answer -- probably some things need to be changed in the code, and
some things should be clarified in the documentation.)

I hope that this (longer) email better clarifies my problem,

	Joachim

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Joachim Schrod				Email: jschrod at acm.org
Roedermark, Germany