The forward search script I had written for vim and mupdf is no longer working since installing TL 2011, and upon investigating why, it seems that synctex is now very fussy about filenames, at least for synctex view. Not only does it require the full path, but it requires a redundant /./ at the end of the path.

To duplicate. Let scratch.tex be:

 Hello world

Now, look at the results of the following from the command line:

kck@kck-desktop ~/tmp $ pdflatex -synctex=1 scratch.tex &>/dev/null
kck@kck-desktop ~/tmp $ synctex view -i 3:1:scratch.tex -o scratch.pdf
This is SyncTeX command line utility, version 1.2
SyncTeX Warning: No tag for scratch.tex
kck@kck-desktop ~/tmp $ synctex view -i 3:1:/home/kck/tmp/scratch.tex -o scratch.pdf
This is SyncTeX command line utility, version 1.2
SyncTeX Warning: No tag for /home/kck/tmp/scratch.tex
kck@kck-desktop ~/tmp $ synctex view -i 3:1:/home/kck/tmp/./scratch.tex -o scratch.pdf
This is SyncTeX command line utility, version 1.2
SyncTeX result begin
SyncTeX result end

Using this syntax for synctex is very counterintuitive, and I'm hesitant to fix my script to use these kinds of filenames for fear synctex's syntax will again be changed.

This problem did not exist for me in TeXlive 2010. Is this change intentional, and will it last?

3 Answers 3


The switch from relative paths to absolute paths is intentional and will stay, as that is a requirement for the --output-directory switch to work.

The fuzzyness with embedded /./ can probably be fixed, but that should be taken up with Jérôme Laurens (the synctex developer). The easiest way to reach him is to send an email message to the TeX Live mailing list. See Tug's texlive homepage for more information.

  • 1
    Yeah, but putting /./ in there is seriously weak sauce, and it breaks apps tightly coupled to distributions that actually embed the synctex library and it's not really easy to swap those out. WTF?
    – towolf
    Oct 25, 2011 at 16:32

I know that this question is rather old, but I thought I'd add my solution since this result came up while I was searching for the cause of the problem.


It appears that what happens is that path names stored within the .synctex.gz file are determined by the kpathsea library. For example, I include each chapter of my thesis from a different file, so my background information is written in the file background.tex. Before the fix, the path name to that file is stored as /home/user/thesis/./background.tex, which is due to the fact that the working directory was /home/user/thesis and the relative path to background.tex according to kpsewhich was

$ kpsewhich background.tex

Putting the paths together, it is easy to see why the synctex file stores /home/user/thesis/./background.tex as the file name. This also suggests the solution though...


The solution is to have kpathsea output a correctly formatted path, and that is accomplished by having kpsewhich not return any relative paths. This is accomplished by setting an environment variable (TEXINPUTS) telling the kpathsea library that the current directory is actually part of the library path. (Note that the trailing colon is necessary. Without it, the default TeXLive paths are forgotten and any standard packages cannot be found. The colon tells kpathsea to also append the default list to the paths given in the environment variable.)

$ TEXINPUTS="$PWD:" xelatex -synctex=1 thesis
$ synctex view -i 3:1:/home/user/thesis/background.tex -o thesis.pdf
This is SyncTeX command line utility, version 1.2
SyncTeX result begin
SyncTeX result end

My favorite way of executing this is to setup latexmk to automatically set the environment variable whenever it is executed. I already used latexmk to simplify the multiple passes required by LaTeX anyway, so why not have it also work around the SyncTeX bug for us as well ;-P. This can be done by either editing your global (~/.latexmkrc) or local ($PWD/.latexmkrc) configuration files. Just add the line


to the file and you'll find that SyncTeX will actually work as expected now (e.g. between gedit and Evince).

  • Using TEXINPUTS and PWD does interesting stuff with symbolic links: in the context of my answer below, the environment variable PWD doesn't resolve symlinks, so the symlinked-path appears in the synctex.gz file, if you used the symlink name when changing directories. On the command line, I would recommend "TEXINPUTS="$(pwd -P):" pdflatex ..." to get the absolute path, and in your .latexmkrc file, use $ENV{TEXINPUTS} = getcwd() . ":";
    – Dan Drake
    Apr 4, 2012 at 11:34
  • @DanDrake, Thanks for the fix. I came up with this solution while trying to fix my thesis build, and since it doesn't make use of any symlinks, I never considered whether there'd be a problem with them or not. I'm sure I'll hit this situation at some point in the future, though, so it's good to know there is a way around it. I've updated my .latexmkrc accordingly.
    – jmert
    Apr 4, 2012 at 15:28

Another problem with this fussiness is symlinked directories. If I have my document in


and a symlink /home/user/foo -> /home/user/long-dir-name, then if my editor uses ~/foo/doc.tex, SyncTeX will be confused since it used ~/long-dir-name/doc.tex.

This requires getting your editor to munge the filename just like kpathsea did, since SyncTeX can't figure out what your editor will think. In Emacs, using (file-truename buffer-file-name) in your elisp seems to work well, along with the above environment variable trick.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.