Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Latexrun fails on long file names #19

Closed
anuragm opened this issue Mar 15, 2015 · 8 comments
Closed

Latexrun fails on long file names #19

anuragm opened this issue Mar 15, 2015 · 8 comments

Comments

@anuragm
Copy link

anuragm commented Mar 15, 2015

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
Copy link
Author

anuragm commented Mar 15, 2015

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
Copy link
Author

anuragm commented Mar 15, 2015

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
Copy link
Owner

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
Copy link

osdf commented Jul 26, 2016

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
Copy link

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
Copy link

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?

Kernald added a commit to Kernald/bazel-latex that referenced this issue Aug 3, 2021
latexrun doesn't properly parse LaTeX's output when the filename doesn't
fit in a single line - see
aclements/latexrun#19. This forces it to use
MAX_INT as a max line length, effectively leaving the line-wrapping job
up to the terminal (which should be its responsibility, not LaTeX's),
and works around this issue.

Fixes ProdriveTechnologies#50
Kernald added a commit to Kernald/bazel-latex that referenced this issue Aug 3, 2021
latexrun doesn't properly parse LaTeX's output when the filename doesn't
fit in a single line - see
aclements/latexrun#19. This forces it to use
480 as a max line length, effectively working around this issue.

Fixes ProdriveTechnologies#50
Kernald added a commit to Kernald/bazel-latex that referenced this issue Aug 11, 2022
latexrun doesn't properly parse LaTeX's output when the filename doesn't
fit in a single line - see
aclements/latexrun#19. This forces it to use
480 as a max line length, effectively working around this issue.

Fixes ProdriveTechnologies#50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants