wrap latex build command

[haraldschilly]

the latex compilation command in the old editor was wrapped via flock

# exclusive lock, wait 5 secs to run or fail, exit code on timeout acquiring lock is 99,	
# release read lock to avoid stuck subprocesses to interfere, file descriptor 9 points to lockfile (derived from tex file)	
flock = "flock -x -o -w 5 9 || exit 99;"	
# yes x business recommended by http://tex.stackexchange.com/questions/114805/pdflatex-nonstopmode-with-tikz-stops-compiling	
latex_cmd = "( #{flock} yes x 2> /dev/null | #{command}; echo '#{sha_marker}'; test -r '#{sagetex_file}' && sha1sum '#{sagetex_file}' ) 9> '.#{@filename_tex}.lock'"

and later

if output.exit_code == 99	
     log = 'Timeout: ongoing concurrent LaTeX operation.'

right now in the new editor, we do see some piling up latex commands. we should come up with an improved solution by maybe picking up on the idea of piping yes x 2> /dev/null | ... into the running command?

figuring out how such a document looks like where this happens to make this reproducible might be very helpful, too...

[haraldschilly]

Ok, this ticket is a bit dusty, but it is still relevant. I just saw a struggle with TikZ, where a missing semicolon in

\begin{tikzpicture}
\draw (0,0)--(-1,0);
\draw (0,0)--(0,1)
\filldraw[black] (0,1) circle (2pt);
\end{tikzpicture}

caused several hanging latex jobs. they were leftover child processes, which weren't cleaned up. The idea regarding "timeout" above is worth a try, unless we're already using it. yes x ... as well. flock is pointless. the tikz example above should be a good enough example to figure out a way to deal with this.

another idea would be to spin up a "full" terminal, which allows a user to interact with the build process and see exactly what's going on (in particular, to see the error message)

[williamstein]

Closing in favor of #3783