[twg-tds] scripts, enc/lig/map

[Paul Vojta]

> Date: Thu, 19 Feb 2004 09:52:24 -0500
> From: karl at freefriends.org (Karl Berry)
> To: vojta at Math.Berkeley.EDU
> Subject: Re: [twg-tds] scripts, enc/lig/map
> 
>     What about platform-dependent executable files (of an auxiliary nature)?
> 
> In practice, don't they just end up in bin?  At least, there is no
> libexec in TeX Live.  Do you have examples (from TeX distributions) in
> mind?  Do we need to specify this?

Well, this begs the question, isn't the same true for platform-independent
scripts?  I guess I should download the latest tetex for examples of
platform-independent scripts that are stored outside of bin.
But, it would seem to me that if you're going to wrap a platform-independent
script, then you might also want to wrap a platform-dependent compiled
executable.  Or, are individual users less likely to modify the compiled
executable, either because it uses a config file, or because it's harder?

I'm generally in favor of planning ahead.

> At any rate, the idea, proposed by Thomas, is that texmf/bin/arch
> contains a script texexec.pl which (more or less) does:
> loc=`kpsewhich --type=scripts texexec.pl`
> exec $loc "$@"
> 
> Right now, this works via a kludge looking for an "other" file named
> texexec.pl.  So the point was to clean that up.

Maybe this could be explained in the spec:  "The intent is not for all
such directories to be added to a user's command search path, but to
have a wrapper script in the normal executable directory which runs
these scripts.  An individual user would then be able to ..."

In general I'd like to see more rationale in the TDS spec; not for relatively
minor questions like scripts/package vs. scripts/perl/package, but for
the big questions like why this directory exists in the first place.

I'd also like to have this directory optional, at the discretion of the
distribution maintainer.  After all, said maintainer may just decide that
it's not worth it adding an extra invocation of kpsewhich in favor of the
flexibility of allowing a user to put a modified script in their own texmf
tree instead of their own bin directory (e.g., I have my own bin directory
but not my own texmf tree; most users maintain their own systems, and therefore
can write to the system texmf/bin if they want; etc.).  The performance
hit of kpsewhich may be relatively small and getting smaller with faster
processors, etc., but it happens every time someone runs the program in
question; on the other hand, I'm inclined to believe that users who modify
these scripts and want to put them elsewhere are very few and far between.

--Paul Vojta, vojta at math.berkeley.edu