[tex-live] [tlpretest]: updmap-sys error
Reinhard Kotucha
reinhard.kotucha at web.de
Thu May 17 19:19:56 CEST 2012
On 2012-05-17 at 18:20:33 +0900, Norbert Preining wrote:
> Hi Uwe, hi Reinhard,
>
> On Do, 17 Mai 2012, Norbert Preining wrote:
> > Please run MANUALLY:
> > mktexlsr c:/Programme/texlive/2012/texmf-config
> > should fix it.
>
> I now know what the problem is ... actually two. One is taht
> I didn't udnerstood how to use the perl mktexupd things.
Hi Norbert,
there is some documentation above the function definition in
TLUtils.pm. Please let me know if something is unclear. The idea is
to collect ls-R entries first and append them to the respective files
at the end in order to avoid duplicate entries.
If entries would be appended to ls-R files immediately, you would get
path_a:
file_1
path_a:
file_2
instead of
path_a:
file_1
file_2
Instead of using a global hash to store paths, mktexupd() returns a
function which can access non-local variables.
> The second, that is for Reinhard:
> *why* are your matching against the lsR trees *case*SENSITIVE*?
> Is there *any* rational reason to do that on Windows?
Certainly not.
> Even if I fix the above and add the proper exec call to the
> updmap script, it still doe snot work, because mkupdmap function
> in TLUtils does not match it (C:/ version c:/).
>
> Are there any reasons for that or can I change that?
I think you can change it for Windows. What I don't understand yet is
where the different spellings come from since all absolute paths are
determined by kpathsea.
Regards,
Reinhard
--
----------------------------------------------------------------------------
Reinhard Kotucha Phone: +49-511-3373112
Marschnerstr. 25
D-30167 Hannover mailto:reinhard.kotucha at web.de
----------------------------------------------------------------------------
Microsoft isn't the answer. Microsoft is the question, and the answer is NO.
----------------------------------------------------------------------------
More information about the tex-live
mailing list