Question: Can I call Git-Bash to issue a command from WSL? Detailed contexts go between the two dividers. (Simple solution appended towards the end of this question.)

I use an alias to compile all my *.tex documents, using Git-Bash on Windows 10. In my c:/users/UserName/.bashrc, I have mapped:

alias lmk='latexmk -pvc -pdf --synctex=1 -src-specials -silent -time -interaction=nonstopmode'

With a native Gvim.exe editor and a Git-Bash instance that hosts the latexmk command, I no longer need to bother with the tedious compilation process.

However, when I issue the same latexmk command through WSL, I can no longer perform forward search and backward search. Some options for the compiler will write to the PDF (or its syntex file), mapping all lines on the PDF to the lines from the source file detailed in WSL-flavored paths. Another way to fix these is to: either opt completely into the WSL world, where I use the native editor + PDF viewer (which is completely new to me), or, to debug further into the compiler and see if I can swap out all the WSL-flavored paths into Windows-flavored paths (which is again, time-consuming).

A simple solution would be, to somehow call Git-Bash from WSL, whereby passing the lmk commands to the Git-Bash as command line arguments?

Aside from the details, in general, is Git-Bash some executable that I can call directly from WSL? If so, how to tell WSL that I would like to run the following "thing"? On my machine, I can find Git-Bash as: "C:\Program Files\Git\git-bash.exe". I tried to pass /mnt/c/Program\ Files/Git/git-bash.exe to WSL, and it has only kindly opened a stand-alone Git Bash window.

enter image description here

One-liner solution using zsh + GitBash

I use zsh as my default shell for WSL, and here goes the function that I defined to make lmk TexFilename.tex directly callable from WSL's command line:

function lmk(){
    "$(wslpath "C:\Program Files\Git\git-bash.exe")" --hide -c "lmk $1"
# Note, the `lmk` here is actually alias from Git-Bash, as defined in: c:/users/UserName/.

The following line makes terminating the hidden bash/perl process handy: issuing lmk_kill shall quite all running compilers (via latexmk, a perl-script).

alias lmk_kill="powershell.exe kill -n perl"

To summarize: with the new zsh function, I am compiling *.tex files from WSL as if I am using the native MikTeX compilers on Windows. This works well with my current settings of GVIM + Sumatra, where both forward and backward search are fully functional.

Even simpler solution: host latexmk through PowerShell

For details, refer to this answer below.

alias lmk='powershell.exe -c latexmk -pvc -pdf --synctex=-1 -src-specials -silent -time -interaction=nonstopmode'

And, compile main.tex files anywhere, say, in a pane of Tmux session on WSL, using simple command lmk main.tex.

  • What is the issue with forward and backward search in WSL? Sometimes simple solution isn't the best.
    – Biswapriyo
    Jul 3, 2019 at 5:45
  • Well, forward and backward search for Vim + Tex + its compilers + PDF-Viewers in WSL are completely different and may not produce desirable result: without getting the fancy jumping things to work, using latexmk to live-compile through WSL and preview PDF through WSL via zathura do not produce reasonable result ==> zathura, the PDF viewer, will blink when the source PDF refreshes and this "blink" can be very distracting as the entire window goes completely black frequently.
    – llinfeng
    Jul 3, 2019 at 13:50
  • @Biswapriyo: here goes my understanding of how forward + backward search can work in WSL ==> one need to have both the editor, the compiler and the PDF viewer all hosted natively in WSL. Otherwise, one need to tweak how latexmk compiles the *.tex file and thus generates the *.synctex files ==> compiler in WSL will write WSL-flavored paths to the *.synctex file, and a normal Windows appliaction (Sumatra.exe, for example) cannot decipher such WSL-flavored paths.
    – llinfeng
    Jul 3, 2019 at 13:53
  • Back to the simple way ==> I find it more pracitcal to get WSL to ask Git-Bash to run something, as it avoid jumping through a number of rabbit holes.
    – llinfeng
    Jul 3, 2019 at 13:55

2 Answers 2


First, with some example. Let a simple command be touch test.txt.

  • In Windows style:
"C:\Program Files\Git\git-bash.exe" --hide -c "touch test.txt"
  • In WSL style:
wsl.exe -- "$(wslpath "C:\Program Files\Git\git-bash.exe")" --hide -c "touch test.txt"

So, how does this work? The -- option after wsl.exe passes the remaining command line as is. Then wslpath converts the Windows style (backward slash) path to WSL/Unix style (forward slash), that is, C:\ becomes /mnt/c (by default). The rest are the options for git-bash.exe. Here are some of them. For further readings, see WSL interoperability with Windows.

  • Great. This is totally working! I set up the following alias in WSL, and got notes as the shorthand for running the compiler for my notes: alias notes='wsl.exe -- "$(wslpath "C:\Program Files\Git\git-bash.exe")" --hide -c "notes"', where the second "notes" is referring to an old alias set in Git-Bash.
    – llinfeng
    Jul 5, 2019 at 14:28
  • One more question though: can I fetch the outputs from Git-Bash when getting WSL to call the intended comands? In the screenshot above, I am referring to those ======= Need to update ... ======= texts that were displayed when running the command natively in Git-Bash.
    – llinfeng
    Jul 5, 2019 at 14:30
  • In theory, you can do all sorts of combination of pipes and grep or find.
    – Biswapriyo
    Jul 5, 2019 at 15:32

There is no need to stay attached to Git-bash at all. The essential requirement in the original post was to compile *.tex documents using native MikTeX on Windows machines. Any command shell that has access to PATH and thereby the latexmk executable can get the job done.

The problem with Git-bash: The git-bash.exe window always starts in its own emulator in a new window, making it impossible to work with Tmux. I now see no need to use Git-Bash for production. Farewell, an old friend of mine :). Nevertheless, running the installer for git from its download page is still the first thing to do when I customize my Windows machine. It provides git.exe that is needed for gvim.exe on Windows.

A practical way to compile *.tex files using Native MikTeX (latexmk)

There are other command shells available on Windows, and all are available for WSL. For example: powershell.exe shall open the PowerShell within the same emulator that hosts the WSL session, making it possible to "host a latexmk compile-process within WSL." This opens the door of hosting multiple "background compilers" through Tmux.

One-liner comamnd to call latexmk from MikTeX, using the native Windows 10 installation:

powershell.exe -c latexmk -pvc -pdf --synctex=-1 -src-specials -silent -time -interaction=nonstopmode 

Usage: assign the long line of command to an alias for the shell used in WSL, like:

alias lmk='powershell.exe -c latexmk -pvc -pdf --synctex=-1 -src-specials -silent -time -interaction=nonstopmode'

Then, from the directory that the main.tex is localed, issue command lmk main.tex to compile the LaTeX document in continous mode. The set of flags that followed latexmk command would also enable backward/forward search.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .