[tex-k] kpse program name

[Joachim Schrod]

>>>>> "KB" == Karl Berry <karl at freefriends.org> writes:

KB>       kpse_set_program_name("dvilj", NULL);
KB>     in a main program, it doesn't take "dvilj" as program name.

KB> "Doesn't take"?

According to the documentation (kpathsea info node "Calling
sequence"), the second parameter of kpse_set_program_name() is
supposed to be used for `the .PROGNAME feature of config files.' (And
by implication also as the prefix for the variable name of formats
kpse_program_{text,binary}_format, though that's not explicated in the
documentation.) If the second parameter is NULL, it's supposed to be
the same as the first parameter.

I.e., after the call cited above, I would have expected that
 kpse_find_file(include_file, kpse_program_binary_format, false) 
uses DVILJINPUTS as environment variable for the search path.

Well, but it does so only on systems where the feature
HAVE_PROGRAM_INVOCATION_NAME is not there. If this feature exists
(i.e., for all systems with GNU libc), the first argument of
kpse_set_program_name() is *not* used as the second argument, but the
program name is taken from program_invocation_short_name. I can pass
whatever I want as first argument; is it effectively ignored.

I.e., this call behaves different if one is on a system with GNU libc
(say, Linux) and without (say, Solaris).

KB> Well, there is code in set_program_name which is conditionally
KB> executed to set the "kpse_program_name" variable, so I don't think
KB> it's completely ignored.

The relevant code in progname.c is:

  if (progname) {
    kpse_program_name = xstrdup (progname);
  } else {
    /* If configured --enable-shared and running from the build directory
       with the wrapper scripts (e.g., for make check), the binaries will
       be named foo.exe instead of foo.  Or possibly if we're running on a
       DOSISH system.  */
    ext = find_suffix (program_invocation_short_name);
    if (ext && FILESTRCASEEQ (ext, "exe")) {
      kpse_program_name = remove_suffix (program_invocation_short_name);
    } else {
      kpse_program_name = xstrdup (program_invocation_short_name);
    }
  }

progname is the 2nd parameter. If HAVE_PROGRAM_INVOCATION_NAME is
not #defined, program_invocation_short_name is constructed from the
1st argument; but otherwise it is taken from GNU libc.

That is the root cause of the inconsistency between the behavior on
Linux and Solaris. If you want, I can create a small example program
that shows the problem.

KB> But indeed, it seems Olaf added reset_program_name specifically to
KB> reset the paths as well.

Well, he did so to reset the path searching when one uses the
%&-feature in TeX -- a behaviour that caused quite some grief in a
recent project of mine. If you're interested to read more about such
practical problems, I'm happy to describe the situation.


KB> Can you propose a patch?  I'm not sure what you were expecting.

Well, I thought the inconsistent behavior between Linux and Solaris
was intended and therefore asked for an improved documentation that
explains that. Now, with your email I'm asking myself if that behavior
was really actually intended.

But you can help me to make up my mind:
Do you know about that inconsistency between GNU libc (e.g., Linux)
and non-glibc systems (e.g., Solaris)?
 -- If no, a discussion about the intended semantics would need to
    happen first.
 -- If yes, the documentation should be changed to point out this
    pitfall. (This would concern the Info nodes "Calling sequence" and
    "Program-specific files"; maybe also the comments in
    progname.[hc].)

I'm willing to propose a batch for any of these two cases, but I'd
need to know the direction first where we need to go.

	Joachim

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