xelatex problem

pviton's picture

xelatex problem

OS: win7, winXP

I can't compile documents using xelatex:
this applies to both 6.0.17 and 6.0.18
(maybe earlier versions too, I don't know).

I tried to diagnose the problem, and I
think there's something wrong with the
way you handle the env variable MSITEXBIN.

1. If I start a dos session and look at this
I get:

C:\>set msitexbin

which is correct. I can check this by
doing, in the same dos session:
set path=%msitexbin% and then calling xelatex.
xelatex starts.

2. However if I modify your xelatex.cmd
and add, at the end,

set msitexbin

and then try to compile eg the std latex
article using xelatex I get:


which is wrong, and doesn't correspond to
the version in the plain dos session.
In addition, based on the now-incorrect path:

C:\Users\pviton\Documents\SWPDocs\untitled2_work\tex>xelatex "main"
'xelatex' is not recognized as an internal or external command,
operable program or batch file.

I don't know where the wrong version of MSITEXBIBN
is coming from, but it's clearly internal to SWP6.

Fortunately there's an easy fix until you
figure it out. On the model of pdflatex.cmd,
edit xelatex.cmd so that the line

set path="%MSITEXBIN%"


set path="%MSITEXBIN%";%path%

With this in place, xelatex works.

Barry MacKichan's picture

I'll make the change to

I'll make the change to xelatex.cmd and related files.

This problem is caused by TeXLive changing the name of the TeX directory tree every year. If you install from our installation, this is taken care of for you, but I agree with you that we have to do better. Right now, installing from a DVD requires setting the contents of the 'year' file. Needs to change. Thanks for the input.



pviton's picture

OK, I understand where the

OK, I understand where the erroneous
MSITEXBIN comes from : it's msitex.cmd.

You seem to be looking for a file
called \.tex\tlyear in the user's
userprofile folder. I've installed TL2015
3 times (once downloading from TUG and twice
from the TUG dvd -- ie not from the SWP6
install) and in no case was this file created.

Is this added only by the SWP6 network
install? If so, it seems pointless to
force the user to potentially install
a new version of TL if there's already
one in place; especially since a network
installation is quite slow.

Some possible solutions:

If the user isn't doing a network
install via the SWP6 installer (which
you can check, right?) assume that
there's already a tex system installed, and
that the path includes it. Then you
can find the folder with the binary
files via

kpsewhich --var-value selfautoloc

(This searches texmf.cnf and presumably
should work on any OS and most other TeX
systems. Other locations can be found similarly).

If you don't want to do this, you could always
go back to the old system where
the installer asks the user to point
to the top-level texmf folder.

Alternatively, if there's already a MSITEXBIN
environment var defined, you could assume that the
user wants to use it, and create the \.tex\tlyear
yourself. Then provide a txt file with an explanation
of what needs to be changed if the user upgrades
TL independently of SWP6.

Are there other possibilities? But one way or
another I think you should regularize this.