Support WSL installs of LaTeX

[Techwolfy]

I use WSL (Windows Subsystem for Linux) on Windows 10, and I'd prefer to avoid duplicate installs of TeXLive and ImageMagick/GhostScript (used for math previews). Unfortunately, it's currently impossible to add linux executables to Windows' PATH variable; they can only be run via bash.exe -c "command" (which calls into the linux environment).

Are there any plans to support this configuration?

[r-stein]

Is this only problematic with the math and image preview? How would you suggest to support that?

[Techwolfy]

It applies to both the TeX binaries and the preview dependencies. WSL essentially acts as an Ubuntu VM that shares the same filesystem as Windows and allows commands to be run via bash.exe. From within the bash shell, it's a normal Ubuntu system (there are a few caveats, but I don't think any of them apply here).

I think the easiest solution would be to add a config option to enable WSL in the Windows section, and switch to the Linux paths wrapped with C:\Windows\System32\bash.exe -c "LATEX_COMMAND_HERE" for external calls when it's set to true.

It looks like external_command.py#L173 controls everything that calls binaries in Windows, so adding the bash.exe call here might be enough; if anything else that uses a fully-qualified external pathname, it would just need an addition to the OS check that runs the Linux code for WSL.

[ig0774]

Not to be negative, but there are a few other considerations that need to be taken into account:

• The block starting at L154 ensures that on Windows, the argument passed is always an array. We'd almost certainly need to ensure that what is passed to bash is a properly escaped string instead.
• To support output_directory, we'd have translate the path (which is sometimes passed as an absolute path) as a valid WSL path.
• Ditto for the preview bits, which write to a folder in the Sublime cache.
• We'd have to figure out how the Sumatra viewer could be supported in this instance (if it's on the system PATH, I'd imagine it more or less works, but if its specified using a setting or found via the registry, there are obviously other problems)
• The preview code depends on our being able to find the ImageMagick executables, which means we'd have to add some sort of check, I suppose by running bash -c which convert, etc.
• In a few place, we rely on the paths returned from executables, e.g., when finding bibliography files in the TEXMF tree or when generating the list of packages used for autocompletions. These would also need to be adapted to WSL.
• We need to ensure that the current working directly properly propagates to bash (there's no reason it shouldn't)
• We'd also need to look at whether the system check works as expected.
• We need to adapt the using_miktex() helper function as well.

None of this requires too much code by itself, but it'll require a fair bit of testing to ensure all the features work as expected.

[jmml97]

How is this going? Any news? Thanks for your work!

[r-stein]

@jmml97 I don't think anyone is currently (or in the near future) working on this.

[alecive]

Differently from @Techwolfy , however, with the latest WSL update even duplicating the installation of latex on both Windows and WSL doesn't seem to be working any more since launching a windows executable in a WSL directory screws up the filesystem making every file broken.

I agree with @ig0774 that this is no small feat, however I'll add my two cents to this conversation [I'm using a similar setup as @Techwolfy ]:

• Sumatra can be retrieved as a Windows executable as before. Calling graphical applications from within WSL is a pain and LatexTools should not be tasked with this. Sumatra interfaces with Sublime and not the Latex build underneath, so I think everything in this regard can be left as-is
• In terms of configuration, it could be possible to use the same convention that gitgutter uses, i.e. an unix like path in the git_binary setting makes git run via Windows Subsystem for Linux. In LatexTools case, a unix-like path would trigger WSL as well for all the executables [not only one].

[alecive]

Additionally, in principle all Linux executables can be run from the command line : https://docs.microsoft.com/en-us/windows/wsl/interop#run-linux-tools-from-a-windows-command-line

Which means that in this case it would only be a matter of having a wsl in front of the executable.

I know I am making it easy when it is not, but I think it would be a great addition to LatexTools!

[LDAP]

I am using a simple workaround: Create a file latexmk.bat or whatever command from wsl you need and add it to Windows PATH. Then add "wsl latexmk %*" to the file. LatexTools is now working correctly but showing a warning concerning log parsing.

Edit: Synctex is also working with sumatra using a script convertig from unix path to windows

[ckunte]

From Tools > Build System > New Build System..., adding the following + saving it as LaTeX.sublime-build enabled building with Ctrl+B:

{
    "cmd" : ["bash", "-c", "/usr/local/texlive/2022/bin/x86_64-linux/xelatex ${file_name}"],
    "shell" : true,
    "working_dir" : "${file_path}",
    "selector" : "text.tex.latex"
}

This worked without the need to install LaTeXTools package on Windows 10 with WSL v2. Any user styles must have the full path (e.g. my custom style ckunte.sty called in the .tex file: \usepackage{/home/ckunte/texmf/ckunte}) for a successful compilation.