Latexrun fails on long file names

[anuragm]

When compiling a file with long name (>48 characters, perhaps?), latexrun fails with error

failed to extract job name from latex log

For example, create a latex file with name

thisisanabsurdlylonglatexfilenamewhichgoesonandonforever.tex

with code

\documentclass{article}
\begin{document}
test
\end{document}

Latexrun fails with error log in terminal

his is pdfTeX, Version 3.1415926-2.5-1.40.14 (TeX Live 2013)
 restricted \write18 enabled.
entering extended mode
(./thisisanabsurdlylonglatexfilenamewhichgoesonandonforever.tex
LaTeX2e <2011/06/27>
Babel <3.9f> and hyphenation patterns for 78 languages loaded.
(/usr/local/texlive/2013/texmf-dist/tex/latex/base/article.cls
Document Class: article 2007/10/19 v1.4h Standard LaTeX document class
(/usr/local/texlive/2013/texmf-dist/tex/latex/base/size10.clo))
(latex.out/thisisanabsurdlylonglatexfilenamewhichgoesonandonforever.aux)
[1{/usr/local/texlive/2013/texmf-var/fonts/map/pdftex/updmap/pdftex.map}]
(latex.out/thisisanabsurdlylonglatexfilenamewhichgoesonandonforever.aux) )</usr
/local/texlive/2013/texmf-dist/fonts/type1/public/amsfonts/cm/cmr10.pfb>
Output written on latex.out/thisisanabsurdlylonglatexfilenamewhichgoesonandonfo
rever.pdf (1 page, 10603 bytes).
Transcript written on latex.out/thisisanabsurdlylonglatexfilenamewhichgoesonand
onforever.log.

failed to extract job name from latex log
There were errors; output not updated

[anuragm]

Not very familiar with Python but perhaps line 839 or 845 needs a regex fix

839:        for m in re.finditer(r'^Transcript written on "?(.*)\.log"?\.$', stdout,
                             re.MULTILINE):
845:        for m in re.finditer(r'^Output written on "?(.*\.[^ ."]+)"? \([0-9]+ page',
                             stdout, re.MULTILINE)

Since the option re.MULTILINE is already there, I am not sure if multiple lines are the problem.

Other work around would be to let pdfLatex generate a log file with bigger column size with option max_print_line like so

max_print_line=200 pdflatex fileName.tex

But then someone would file the bug again with bigger file name :). Not sure if this would be a way to go.

[anuragm]

I don't have much experience in Python, but I have a quick fix here

https://github.com/anuragm/latexrun/commit/e10f75520f57caa170840b237241129543cdd0c8

Should I send in a pull request?

[aclements]

Thanks for the report! Sorry I was so slow to respond. I just merged pull request #22, which fixed this in almost exactly the same way your patch did.

[osdf]

Hi there. I'd like to reopen this issue. We stumbled over the special case of log. being on a single line, i.e.

Transcript written on latex.out/exactly_as_many_chars_for_this_case.
log.

I tried a few quick ideas but couldn't get the regex working for this case. Any idea/help?

As a tiny addon, it would be nice if the resulting error message from latexrun would have an indicator that it is coming from latexrun and not from pdflatex, eg. something like [latexrun] in front of the two error lines.

[TobsCore]

I had this issue on Windows with Cygwin, where XeLaTeX is configured to wrap lines after 79 characters. This was fixed by changing the max characters per line in a config file (See https://tex.stackexchange.com/questions/52988/avoid-linebreaks-in-latex-console-log-output-or-increase-columns-in-terminal for more information.

[make-github-pseudonymous-again]

One could also merge lines that hold exactly 79 characters before extraction of the job and output names. But that number depends on configuration as noted above. Maybe this number can be guessed from stdout: some lines end with a trailing space indicating a truncated line. Though it might be that some lines are exactly 79 characters long while not being the product of truncation.

[make-github-pseudonymous-again]

This issue has actually been reopened and tentative solutions have been suggested elsewhere: see #29, #58, #59, #66.

[The-Compiler]

This issue still is marked as closed FWIW 😉

As a workaround, it's possible to run max_print_line=120 latexrun ..., see a relevant stackoverflow answer - perhaps latexrun should set that in its environment (perhaps to 999 or something) when launching pdflatex, so it doesn't need to accommodate for line-wrapping at all?