Sublime Forum

[BUG] Launching external commands with Popen

#1

Updated 10/23: put [BUG] in title, clarified a few issues about the test script.

I am having a weird issue with subprocess.Popen as invoked from my LaTeXTools plugin. A user reported the following bug: a LaTeX file containing a picture originally in eps format fails to compile when building from ST2, but builds just fine when invoking the exact same command that the plugin uses from the command line.

What’s special (sort of) about this file is that the LaTeX graphics package, upon encountering the eps file, is smart enough to invoke the epstopdf command from within tex, and then import the resulting pdf file. This is what fails under ST2.

I can confirm that running the appropriate latex build command from the command line works just fine. In fact, I wrote a python script that invokes the exact same command used by the LaTeXTools plugin, using subprocess.Popen—again, this is copied line by line from the plugin. The results: if I run the script from the command line, everything works. If I run the script from within the ST2 console, I have exactly the same behavior that I observe when I build from ST2. I reproduce the script below for convenience.

What is going on? Is there some limitation on processes run from ST2 that in turn spawn other processes? Note that TeXshop has no trouble at all with eps file conversion on the fly.

Here’s the script. Again, this is not the plugin code: just a standalone test script. The actual plugin code gets the file name from the current view, etc. Also note that the path is set so tex and friends (including epstopdf) are reachable. Also, I tested this on OS X; I haven’t tried it on Windows. The problem exists up to the current release, 2134.

import sys, os, os.path
import subprocess

make_cmd = "latexmk", 
		"-e", "$pdflatex = q/pdflatex %O -synctex=1 %S/",
		"-f", "-pdf"]

file_name = os.path.normpath("/Users/xxxxx/Documents/temp/sublimeTests/epstest/epstest.tex")
tex_dir = os.path.dirname(file_name)

cmd = make_cmd + [file_name]
print cmd

path = "$PATH:/usr/texbin"
old_path = os.environ"PATH"]
os.environ"PATH"] = os.path.expandvars(path).encode(sys.getfilesystemencoding())

os.chdir(tex_dir)
proc = subprocess.Popen(cmd)
proc.wait() 

os.environ"PATH"] = old_path

print proc.returncode
0 Likes

#2

It may be a path issue. ST2 does not inherit the shell environment, and by default PATH is /bin:/sbin:/usr/bin:/usr/sbin.

0 Likes

#3

I don’t think so. Notice that I set the path in the test script, which is exactly what I do in the plugin. All (la)tex executables are on /usr/texbin, including epstopdf…

0 Likes

#4

Bump…? Jps?

0 Likes

#5

I can second this behavior. In my LaTeX-case it results in not compiling any eps files into pdf files.

See my post here: http://www.sublimetext.com/forum/viewtopic.php?f=3&t=3386&start=0

0 Likes

#6

Thanks trinix. Jon, the question is, are there any restrictions imposed on a process that is launched via subprocess.Popen from ST2? For instance, are stdin/stdout redirected? Again, subprocess.Popen works (i.e. latexmk runs just fine, invoking epstopdf) if the test Python script (which contains essentially the same relevant code as the plugin file make_pdf.py) is run from the command line (i.e. the Terminal).

Any ideas?

0 Likes

#7

What about this issue? It makes me more and more unable to work on certain LaTeX-projects which need dealing with EPS files!

0 Likes

#8

Jon, how can I help you track this bug down?

0 Likes

#9

Maybe encoding each parameter with

aParameter.encode(sys.getfilesystemencoding())

And on Windows you need to escape “^” character such

string.replace('^', '^^')
0 Likes

#10

you can also try using cwd= parameter instead of changing dir.

0 Likes

#11

It’s almost certainly a path issue. Rather than setting $PATH, try providing a full path to the executables and see if that helps.

0 Likes

#12

So I added the full path to the “cmd” option in LaTeX.sublime-build, and also to the “-e”, “$pdflatex = …” line (which gets passed to latexmk). Nothing seems to work… I am really at my wits’ ends on this one :frowning:

0 Likes

#13

Hrm… explicit paths won’t help, as the issue is presumably that when epstopdf is launched, it’s expected to be in the path, which is likely isn’t. Sublime Text itself doesn’t do anything with Popen, there should be no difference between calling Popen within Sublime Text or within Python, except for the difference in $PATH.

Take a look at stackoverflow.com/questions/5658 … nment-path, I believe the answer given there (either set the path with env=… and use shell=True, or run the process via /usr/bin/env) should solve this issue.

0 Likes

#14

Grr… so I tried adding

env = {“PATH”: }

to the subprocess.Popen call: no dice. I added /usr/bin/env, i.e. doing

subprocess.Popen(’/usr/bin/env’] + cmd)

where cmd is the list containing the latexmk command: nothing. I added shell=True, and here what happens is, mysteriously, latexmk produces a dvi file instead of a pdf file.

I am not sure that the path is the problem. When I run the python script in the first post of this thread, everything works just fine, even though I do not have tex & friends on my path (i.e. typing “latexmk” at the prompt gives “-bash: command not found”.

:frowning:

0 Likes

#15

Following along with sublimator’s suggestion, try launching Sublime Text from the terminal, rather than from finder, e.g.,

  • Quit Sublime Text 2
  • run “/Applications/Sublime Text 2.app/Contents/MacOS/sublime_text” from the terminal
  • check on.environ in the console to verify that it’s different from os.environ when launched from Finder

It’d be interesting to see if that helps the issue.

(I realise I’m just parroting the above message, but it’s not always obvious how to launch an application from the terminal in OS X)

0 Likes

#16

THANKS!!!

I think I solved the mystery. Launching ST2 from the console works. /usr/texbin is NOT on the path, but that’s NOT what’s causing users problems. The epstopdf command invokes ghostscript, which (on OSX) is in /usr/local/bin. So, adding /usr/local/bin to the “path” variable in LaTeX.sublime-build fixes the issue.

Thanks!!!

0 Likes

#17

I assume you have already looked at the Console (for logs) and the Activity Monitor (for processes)?

0 Likes