<html><head></head><body><div style="color:#000; background-color:#fff; font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px"><div>I may have been the first to suggest a wrapper script and the settings of the PATH variables.</div><div id="yui_3_16_0_ym18_1_1458285883891_2737"><br></div><div id="yui_3_16_0_ym18_1_1458285883891_2738">If one makes a wrapper script with the same name as the engine (not a very clever idea, but a good quick & dirty hack with a minimum of changes to TeXWorks) then all you need to do is set the PATH in such a way that the wrapper script is found before the actual executable; that means that all other PATH settings remain intact.</div><div id="yui_3_16_0_ym18_1_1458285883891_2884"><br></div><div id="yui_3_16_0_ym18_1_1458285883891_2882">Cheers,</div><div id="yui_3_16_0_ym18_1_1458285883891_2883">Wilfred<br></div><div id="yui_3_16_0_ym18_1_1458285883891_2694"><span></span></div> <div class="qtdSeparateBR"><br><br></div><div style="display: block;" class="yahoo_quoted"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;"> <div dir="ltr"><font size="2" face="Arial"> On Friday, March 18, 2016 3:33 PM, "mskala@ansuz.sooke.bc.ca" <mskala@ansuz.sooke.bc.ca> wrote:<br></font></div> <blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; margin-top: 5px; padding-left: 5px;"> <br><br> <div class="y_msg_container">On Fri, 18 Mar 2016, Reinhard Kotucha wrote:<br clear="none">> > hboxes, as directly as possible. A script that replaces TeX can<br clear="none"><br clear="none">> Matthew, honestly, I don't think that people didn't understand your<br clear="none">> suggestion. There are just a few problems and there is no real<br clear="none">> benefit, IMO.<br clear="none">><br clear="none">> You suggested to put the wrappers into PATH and call the real programs<br clear="none"><br clear="none">Maybe someone else suggested that; several people here have advocated<br clear="none">wrapper scripts and I wasn't the first to do so. I don't think I<br clear="none">mentioned the PATH variable myself before now at all.<br clear="none"><br clear="none">I was actually thinking of leaving XeTeX where it is, under its original<br clear="none">name, giving the wrapper script some completely different name, and then<br clear="none">telling TeXworks to use the new name - which I expect should be possible<br clear="none">because TeXworks already is capable of running multiple backends. If<br clear="none">TeXworks hard-codes the list of possible names of the TeX engine, then<br clear="none">yes, it might be necessary to name the script something TeXworks can<br clear="none">call... but possibilities for leaving it in place could include giving the<br clear="none">script the name of some other TeX engine TeXworks can invoke (ugly, but<br clear="none">it'd work) or putting the script in a PATH directory searched before the<br clear="none">one that contains real XeTeX, so that it can replace real XeTeX without<br clear="none">touching any other executables.<br clear="none"><br clear="none">There's an issue here of which I've been trying to politely not make a big<br clear="none">deal, but:<br clear="none"><br clear="none">We have only one user demanding this. If we even care at all, then we<br clear="none">don't need a solution for everybody. Just him.<br clear="none"><br clear="none">That means questions of portability to all operating systems, or of<br clear="none">compatibility with software and features he doesn't use, are not really<br clear="none">significant. It also means the question "Who should write new code?" is<br clear="none">not the false dilemma Philip Taylor has repeatedly claimed, with the<br clear="none">answer necessarily being either "all TeX engine maintainers!" or "all<br clear="none">front end maintainers!"<br clear="none"><br clear="none">It isn't *all* of any open-ended group.<br clear="none"><br clear="none">It's *one* person who wants his system to operate differently, who could<br clear="none">have that by writing a script himself, and who has succeeded in winding us<br clear="none">up to treat his very personal use case as if it needed to be universal.<br clear="none"><br clear="none">TeXworks; XeTeX (and specifically not XeLaTeX); whatever operating system<br clear="none">Philip Taylor uses. Not all front ends; not all TeX engines; not any<br clear="none">LaTeX-specific feature; not all operating systems; only one user. This is<br clear="none">not a general issue and it does not need a universally portable solution.<br clear="none"><br clear="none">> another program which is supposed to be in PATH. Nowadays EPS files<br clear="none">> are converted to PDF on-the-fly, if necessary. But it can only work<br clear="none">> if the directory containing the TeX Live binaries is in PATH so that<br clear="none">> epstopdf can be found.<br clear="none"><br clear="none">Is that a TeX feature or a LaTeX feature? Mr. Taylor famously doesn't use<br clear="none">LaTeX, so if it's a LaTeX feature, breaking it doesn't matter - but it'd<br clear="none">only be broken if epstopdf were taken out of PATH anyway, which I did not<br clear="none">recommend. (Does whatever searches for epstopdf even use PATH anyway?<br clear="none">I'd've expected it to use kpsewhich, independently of PATH. But this<br clear="none">isn't relevant!)<br clear="none"><br clear="none">Even if it were necessary to take the real XeTeX out of PATH - which is<br clear="none">not the case - why would that have anything to do with changing the name<br clear="none">or location of epstopdf?<br clear="none"><br clear="none">> Your suggestion implies that there are two programs with the same<br clear="none">> name name in different directories. This is nasty and certainly<br clear="none"><br clear="none">No, I intended that the script should not be named "xetex" and that real<br clear="none">XeTeX should remain where it is. If TeXworks hardcoded the name so that<br clear="none">the script were forced to be named "xetex", then yes, things would become<br clear="none">more complicated, but I don't think that is actually the case, and even if<br clear="none">it were, it would not be a dealbreaker.<br clear="none"><br clear="none">> causes more problems than it solves. And please consider that there<br clear="none">> are zillions of TeX engines/formats nowadays and you need wrappers for<br clear="none">> all of them.<br clear="none"><br clear="none">Only the engine that one user uses, and it only has to work on his system.<br clear="none"><br clear="none">> order to save time. But if your wrapper scans the log file in order<br clear="none">> to determine the proper exit status, you don't save any time at all.<br clear="none"><br clear="none">I think most of us agree that saving computation time is not a real<br clear="none">consideration here. You say so yourself, below.<br clear="none"><br clear="none">> The best solution is to run a script which inspects the log file after<br clear="none">> each TeX run.<br clear="none"><br clear="none">Yes, that's what I said.<br clear="none"><br clear="none">Apparently TeXworks's built-in feature for running postprocessing scripts<br clear="none">isn't suitable for this purpose because the scripts run by that feature<br clear="none">aren't able to tell TeXworks that TeX has "failed" in the way that causes<br clear="none">it to open a log window, which was was what the user wanted. But a<br clear="none">wrapper script could do it by returning a nonzero exit code, so I think a<br clear="none">wrapper script is the best solution.<br clear="none"><br clear="none">> Emacs/AUCTeX is doing this for more than two decades.<br clear="none">> Programming languages like Perl or Lua are probably even faster than<br clear="none">> Emacs Lisp. Not to mention that computers are much faster than 20<br clear="none">> years ago.<br clear="none"><br clear="none">Indeed.<br clear="none"><br clear="none">> Phil assumed that scanning the log file is time consuming and thus<br clear="none">> suggested configurable exit values. But as Zdeněk already pointed<br clear="none">> out, scanning the log file is not time consuming at all.<br clear="none"><br clear="none">I agree.<br clear="none"><br clear="none">-- <br clear="none">Matthew Skala<div class="yqt4264024019" id="yqtfd90364"><br clear="none"><a shape="rect" ymailto="mailto:mskala@ansuz.sooke.bc.ca" href="mailto:mskala@ansuz.sooke.bc.ca">mskala@ansuz.sooke.bc.ca</a></div> People before principles.<br clear="none"><a shape="rect" href="http://ansuz.sooke.bc.ca/" target="_blank">http://ansuz.sooke.bc.ca/</a><br><div class="yqt4264024019" id="yqtfd93785"><br clear="none"><br clear="none">--------------------------------------------------<br clear="none">Subscriptions, Archive, and List information, etc.:<br clear="none"> <a shape="rect" href="http://tug.org/mailman/listinfo/xetex" target="_blank">http://tug.org/mailman/listinfo/xetex</a><br clear="none"></div><br><br></div> </blockquote> </div> </div> </div></div></body></html>