[tex-live] kpsewhich
Olaf Weber
olaf at infovore.xs4all.nl
Fri Mar 26 22:20:17 CET 2004
Hans Hagen writes:
> At 19:55 26/03/2004, Olaf Weber wrote:
>>> so, maybe we should look at all scripts/tools and get rid of all
>>> things that somehow may interfere with os specific things, a kind of
>>> micro tex-os like environment built into kpse:
>>> kpsewhich --envvar=WHATEVER
>>> then returns the meaning of $WHATEVER or %WHATEVER% or WHATEVER* the
>>> os env var is set to
Note that the syntax of environment variables is not determined by the
OS. It is determined by the interpreter retrieving the variables.
Where command.com wants %FOO%, bash on the same OS wants $FOO.
The problem seems to be that handing off a command to the "default
interpreter" with a system(3) call is problematic, because the
interpreter will interpret the string in an interpreter-specific
manner.
>> This works for a single variable. It does not work for more general
>> expressions, like
>> kpsewhich -expand-path='{$SYSTEXMF}/fonst'
> hm, then how about some kind of syntax:
> -expand-path='var(SYSTEXMF)/fonts'
> that would be upward compatible, wouldn't it?
Not really, as it turns previously-uninterpreted text into something
that is interpreted.
Of course, what happens when I run this on an OS where the default
interpreter has its own ideas on the meaning of 'var(...)'?
What you need for this is to use an interpreter that can, in a way
that is common to all its incarnations on different OSes, be
instructed to start _this_ command with _these_ arguments, and have
the arguments treated as literal strings. If the interpreter doesn't
allow for that, than _it_ cannot be used for OS-independent work that
involves calling helper programs.
--
Olaf Weber
(This space left blank for technical reasons.)
More information about the tex-live
mailing list