[texworks] Suggestion: set the PATH before running tools

Duncan Murdoch murdoch.duncan at gmail.com
Sun Dec 4 17:46:52 CET 2022


On 04/12/2022 10:51 a.m., Stefan Löffler wrote:
> Dear Duncan,
> 
> On 30.11.22 21:05, Duncan Murdoch wrote:
>> TeXworks 0.6.7 on MacOS has an editable list of paths in Preferences |
>> Typesetting.  Presumably these are used by it when looking for any of
>> the tools listed in the Processing Tools settings.
> 
> Yes. The list is initially populated (when TeXworks is first run) by a
> pre-generated list of "typical default path guesses". TeXworks then uses
> that list, plus the directories in PATH (as seen by TeXworks) as
> fallbacks, to look for programs to run.
> 
>> However, those tools will see the standard PATH environment variable
>> that TeXworks saw when it started.
> 
> Not quite. On macOS, the directory the currently executed program was
> found in is appended to the PATH prior to starting the tool. This is
> precisely so that additional tools available alongside the program
> (hopefully) work.
> The key word is "alongside", if they are in a
> completely different directory this approach will not help, of course.
> Unfortunately, the handling of PATH is complex (particularly on macOS).
> I seem to remember (though maybe incorrectly) that the initial PATH
> depends on how you started TeXworks (from the GUI, with `open
> TeXworks.app` from the terminal, or with
> `TeXworks.app/Contents/MacOS/TeXworks` from the terminal). In some
> cases, the full PATH available in a terminal might be seen, while in
> other cases only a small "default set" (/usr/bin + /usr/local/bin) is
> available.

I believe MacOS uses the standard Unix approach:  a process is given 
environment variables (including PATH) from the process that starts it.
The parent process can just let the child inherit what it has, or set up 
something new.  The differences you saw come from the fact that apps are 
started from a launch daemon if you click on them, but from the shell if 
you start them there.  Shells run startup scripts that typically modify 
the PATH.

In the case of Typesetting tools run in TeXworks, the tool will inherit 
the PATH that's in effect in TeXworks unless you specify something 
different.  This will vary depending on whether TeXworks was started 
from the launcher or from a shell.

> 
>> This means for example that scripts using pdflatex might not be able
>> to find it, even though TeXworks itself knows where it is.
> 
> If you mean that you have, e.g., a (non-shell) script which simply
> invokes pdflatex and is run from /some/custom/folder, it will not find
> pdflatex if that is installed, e.g., in /opt/texlive. Invoking it with
> the full path should obviously work, though.
> If you have a shell script, my understanding is that first a shell would
> need to be started, which would (hopefully?) set up PATH correctly
> according to the config files.

I'm generally running things from R, not from a shell.  It just sees 
what TeXworks gives it.

> 
>> Since editing the PATH seen by apps on MacOS is a pretty obscure
>> exercise, my suggestion is that TeXWorks should append the entries
>> from Preferences | Typesetting to the PATH before running the other
>> tools.
>> (It could be fancy and only append the entries that aren't already
>> there, but that's not really necessary.)
> 
> As outlined above, TeXworks does append the directory the program is
> found in to PATH. This is done to act as a sort of fallback, but give
> precedence to all the other directories that may be in PATH. Adding all
> entries in the list would be possible, but could get rather messy (in
> case there are many entries), and could result in all sorts of other
> confusion (e.g., if you have two versions of TexLive installed, say 2020
> and 2021, but with different installed tools, you might end up invoking
> mismatching tools from different versions). Personally, I would like to
> keep programmatic PATH modifications to a minimum, in case some users
> more knowledgeable with macOS than me find good ways of actually
> exposing the PATH they want in the first place.

I don't see how my proposal would increase the risk of finding a 
mismatched version, but thanks for thinking about this.

Duncan Murdoch




More information about the texworks mailing list.