GNU bug report logs - #65628
Document preview fails with long filenames

Previous Next

Package: auctex;

Reported by: John Holman <john.g.holman <at> gmail.com>

Date: Wed, 30 Aug 2023 16:36:02 UTC

Severity: normal

Tags: notabug

Done: Ikumi Keita <ikumi <at> ikumi.que.jp>

Bug is archived. No further changes may be made.

Full log


Message #8 received at 65628 <at> debbugs.gnu.org (full text, mbox):

From: David Kastrup <dak <at> gnu.org>
To: John Holman <john.g.holman <at> gmail.com>
Cc: 65628 <at> debbugs.gnu.org
Subject: Re: bug#65628: Document preview fails with long filenames
Date: Wed, 30 Aug 2023 19:35:13 +0200
John Holman <john.g.holman <at> gmail.com> writes:

> Hi. I'm not sure that the problem was captured in the log below created
> by preview-report-bug so a few more details first:
>
> Running auctex on windows 11 with MiKTeX
>
> Test file contents (but most files containing maths seem to trigger the
> problem)
>
> \documentclass{article}
> \begin{document}
>
> \(x=y\)
>
> \end{document}
>
> Document preview works when the filename has no more than 22 characters,
> e.g. test.tex, but fails with message "Ghostscript filter: No bounding box"
> when the filename has more, e.g. 01234567890123456789012.tex. However
> buffer preview always works.
>
> When document preview fails the maths sections are replaced with the
> roadworks signs indefinitely. The 01234567890123456789012.prv directory is
> created
> containing a temp folder containing a preview.dsc file but no png
> images. The rungs.exe and mgs.exe processes don't exit until killed manually
> or emacs is closed.
>
> The contents of the *.. output* buffer are then
>
> Running `Preview-LaTeX' on `012345678901234546789012' with ``pdflatex
>  -file-line-error
>  "\nonstopmode\nofiles\PassOptionsToPackage{active,tightpage,auctex}{preview}\AtBeginDocument{\ifx\ifPreview\undefined\RequirePackage[displaymath,floats,graphics,textmath,sections,footnotes]{preview}[2004/11/05]\fi}"
> "\input" "\detokenize{" "012345678901234546789012.tex" "}"''

Probably exceeding a total command line length of 256 characters or some
similar Windows restriction.  I also seem to remember that some Windows
file system or API limited the length of absolute filenames you could
access even when only using relative filenames, so the length of the
directory path you are in might also play a part here.

-- 
David Kastrup




This bug report was last modified 1 year and 268 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.