thomasjo / atom-latex

Compile LaTeX or knitr documents from within Atom
https://atom.io/packages/latex
MIT License
223 stars 42 forks source link

Latexmk fails to work due to bad filename(s) #480

Closed GauSyu closed 5 years ago

GauSyu commented 6 years ago
2018-08-09 15 59 17

As the log showing, latexmk fails to work because of my filename. However, this happens only after I update my Texlive: it works fine in the past, for the same file. I wonder what causes this problem and how to fix it (probably through relative path, which i don't know how to set up).

dsferruzza commented 6 years ago

Same here! (with MiKTeK on Windows 10)

I'm pretty sure this is because I updated latexmk from 4.55 to 4.59. I'm still able to compile my project using latexmk -pdf article.tex from the command line, only atom-latex gives me this error.

zoenglinghou commented 6 years ago

I can confirm the issue. I am using MacTeX on macOS 10.12. It happens in atom-latex, but not in terminal.

$ latexmk -version

Latexmk, John Collins, 7 August 2018. Version 4.59
stale[bot] commented 6 years ago

This issue has been marked as stale because due to inactivity. It will be closed in 7 days if no further activity occurs.

Aerijo commented 6 years ago

@thomasjo This just happened to me; I was also working an iCloud folder, and had just updated everything with tlmgr. Downgrading back to the stored backup version of latexmk made the issue go away, so it's definitely related to that recent(?) update.

I couldn't reproduce in a folder within my home directory, so I'm guessing the iCloud path is important (most likely the space in Mobile Documents, or the tildes).

zoenglinghou commented 6 years ago

I think the issue pertains to iCloud folder path contains tildes ~, and latexmk does not accept such file path. It is strange, because it used to work. LaTeX Workshop's issue explained this

Aerijo commented 6 years ago

latexmk deliberately throws an error now when the provided command line path has invalid(?) characters. I say invalid(?), because it was working fine for years in iCloud before this arbitrary change.

He doesn't seem to have added a flag to disable this either. I guess the only way to get around it would be to use relative paths. I believe that's why it still worked fine directly in the terminal.

hannahedavis commented 6 years ago

I've run into this issue as well, with MikTeX and Windows 10, on a filename that does not include tildes (but does include backslashes, because Windows).

jerome-benoit commented 6 years ago

Same as @polestarneighbor with the texlive 2018 distribution for windows.

Running latexmk from the command line inside the directory containing the .tex file just works.

scrouthtv commented 6 years ago

Same for me (Windows 10 / texlive). Anyone knows how to fix?

thomasjo commented 6 years ago

Judging from all of the various comments, it seems like the change in Latexmk will require us to "sanitize" paths. Will have to figure out exactly what types of characters are considered invalid though. That effort will most likely require digging through the code in the latexmk Perl script.

Aerijo commented 6 years ago

@thomasjo See this. In the file latexmk.pl, line 337

thomasjo commented 6 years ago

@Aerijo Yeah, just looking at it now. It actually looks like the problem might be the fact we wrap file paths in double quotes ("), which has always worked, but is somehow "invalid" now...

If we have to avoid quoting paths, we will have to change how we execute latexmk, since this change means we cannot use absolute paths. We might have to change the working directory of child process to the project root, such that we can use relative paths.

Aerijo commented 6 years ago

@thomasjo

the problem might be the fact we wrap file paths in double quotes ("), which has always worked, but is somehow "invalid" now...

No, he explicitly added that part I mentioned to make it throw an error when it sees those characters in the path. The only way to have a ~ in the path would be to ... not have one, hence why relative paths seem to be the only option.

thomasjo commented 6 years ago

Yeah, you're right! I was reading the comment and didn't actually double check that it matches the regex.

Still, that pattern doesn't explain the problem path in #494 — C:\Users\[.....]\Dropbox\github\PhD-Notes\Comprehensives\testing.tex — unless their username contains an unusual character (which is unlikely given it's a Windows system).

Regardless, looks like we'll have to re-engineer how we execute Latexmk... :sob:

scrouthtv commented 6 years ago

For me, "the invalid filenames" error was gone / fixed by uninstalling TexLive & using MikTeX instead...

I think TL is missing some binaries for Windows, could that be it?

jerome-benoit commented 6 years ago

On 31/10/2018 14:41, scrouthtv wrote:

For me, "the invalid filenames" error was gone / fixed by uninstalling TexLive & using MikTeX instead...

I think TL is missing some binaries for Windows, could that be it?

No, TL contains more binaries that are more recent than the ones in MikTeX.

-- Jérôme Benoit aka fraggle Piment Noir - https://piment-noir.org OpenPGP Key ID : 27B535D3 Key fingerprint : B799 BBF6 8EC8 911B B8D7 CDBC C3B1 92C6 27B5 35D3

pbregener commented 6 years ago

For me, "the invalid filenames" error was gone / fixed by uninstalling TexLive & using MikTeX instead...

Not for me using MikTeX on Windows 7 (and I have never had TL installed on this machine). Still the same problem.

scrouthtv commented 6 years ago

@pbregener try switching to DiCy and disabling Extended Build Mode... I think there are some major errors when trying to use the addon on Windows.

pbregener commented 6 years ago

@scrouthtv I can try but it used to work just fine (until a recent Atom and/or latexmk update).

Aerijo commented 6 years ago

@pbregener This package uses your computer's latexmk. You should be able to fix any recent issues by reverting to an earlier latexmk version. Can you let us know if that works? (if it doesn't, then it may well be an issue in this package, besides the known issue).

pbregener commented 6 years ago

@Aerijo Sure, I will try that on Monday. Luckily, I am only running Windows on my work computer.

pbregener commented 6 years ago

Current Atom and current atom-latex work fine with up-to-date MikTeX on Windows 7 and latexmk up to version 4.57 (released in June 2018). Later versions of latexmk lead to Stopping because of bad filename(s).

So exactly as reported in the first comments of this issue.

Older versions and changelog at http://personal.psu.edu/jcc8/software/latexmk/versions.html

zoenglinghou commented 5 years ago

I emailed the author of latexmk, and I asked him if it is possible to allow ~ in directory names. I am waiting for his response at the moment.

Aerijo commented 5 years ago

@CarlosEvo It's not so much allowing ~, as it is making the entire check optional via a flag that would help.

Using relative paths as in #499 should also work though, at least in the case where it's a directory higher up than the project that contains bad characters.

zoenglinghou commented 5 years ago

@Aerijo That’s true, but I kinda did that for vscode compatibility, since the developer has no plan for such accommodation.

zoenglinghou commented 5 years ago

The author agreed to make changes to the code. From now on, by adding -cd option, the directory can have the weird characters.

thomasjo commented 5 years ago

@CarlosEvo That's great news! We're currently not using the -cd option though because we're currently relying on execution to always be rooted in the project directory. Unless I'm mistaken, if use the -cd option all build output will be located relative to the file being processed, instead of the working directory (which in our case is the project directory). This would likely break a lot of existing functionality.

thomasjo commented 5 years ago

We think this has (temporarily) been fixed by #499, thanks to @Aerijo. Please see that PR for more details. If you encounter any problems with the proposed workaround, please open a new issue.

zoenglinghou commented 5 years ago

@thomasjo from my understanding, -cd option only change the directory temporarily in the compiling process. Not sure how it would interfere tho. Quote from the author, FYI:

See the documentation. -cd takes no arguments. What it tells latexmk is that when the name of tex file contains a non-trivial directory component, then latexmk should change directory to the directory of the tex file before compiling it.

jackbshim commented 5 years ago

On Windows 10, texlive. I had this issue as well, despite not having any tildes around in my filename. (there was a space though)

I think the problem is that the package is feeding in Windows-style filenames (with backslashes) into latexmk, while it expects a unix style filename.

I did a little experiment to test my hypothesis: on powershell I tried latexmk -pdf for both windows style and unix style file paths. Here's what I got:


PS H:\my drive\notes\test> dir

    Directory: H:\my drive\notes\test

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
------         4/3/2019  12:13 PM             70 test.tex

PS H:\my drive\notes\test> latexmk -pdf "H:\My Drive\Notes\test\testfile.tex"
Latexmk: This is Latexmk, John Collins, 25 October 2018, version: 4.61.
Latexmk: Filename 'H:\My Drive\Notes\test\testfile.tex' contains character not allowed for TeX file.
Latexmk: Stopping because of bad filename(s).
C:\Dev\texlive\2018\bin\win32\runscript.tlu:902: command failed with exit code 2:
perl.exe c:\Dev\texlive\2018\texmf-dist\scripts\latexmk\latexmk.pl -pdf "H:\My Drive\Notes\test\testfile.tex"

PS H:\my drive\notes\test> latexmk -pdf "/h/my drive/notes/test/testfile.tex"
Latexmk: This is Latexmk, John Collins, 25 October 2018, version: 4.61.
Latexmk: applying rule 'pdflatex'...
Rule 'pdflatex': Rules & subrules not known to be previously run:
   pdflatex
Rule 'pdflatex': The following rules & subrules became out-of-date:
      'pdflatex'
------------
Run number 1 of rule 'pdflatex'
------------
------------
Running 'pdflatex  -recorder  "/h/my drive/notes/test/testfile.tex"'
------------
This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018/W32TeX) (preloaded format=pdflatex)
 restricted \write18 enabled.
entering extended mode
(h:/My Drive/Notes/test/testfile.tex
LaTeX2e <2018-12-01>
(c:/Dev/texlive/2018/texmf-dist/tex/latex/base/article.cls
Document Class: article 2018/09/03 v1.4i Standard LaTeX document class
(c:/Dev/texlive/2018/texmf-dist/tex/latex/base/size10.clo)) (./testfile.aux)
[1{c:/Dev/texlive/2018/texmf-var/fonts/map/pdftex/updmap/pdftex.map}]
(./testfile.aux) )<c:/Dev/texlive/2018/texmf-dist/fonts/type1/public/amsfonts/c
m/cmr10.pfb>
Output written on testfile.pdf (1 page, 11841 bytes).
Transcript written on testfile.log.
=== TeX engine is 'pdfTeX'
Latexmk: Log file says output to 'testfile.pdf'
Latexmk: All targets (testfile.pdf) are up-to-date
PS H:\my drive\notes\test> dir

    Directory: H:\my drive\notes\test

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
------         4/3/2019  12:13 PM             70 testfile.tex
------         4/3/2019  12:21 PM              8 testfile.aux
------         4/3/2019  12:21 PM           1211 testfile.fdb_latexmk
------         4/3/2019  12:21 PM            740 testfile.fls
------         4/3/2019  12:21 PM           2382 testfile.log
------         4/3/2019  12:21 PM          11841 testfile.pdf

So it compiles if I use "/h/my drive/notes/test/testfile.tex"', but fails with "H:\My Drive\Notes\test\testfile.tex" with exact same error output. Error message from the package is attached below:

aaa

PabloLION commented 4 years ago

try this https://github.com/James-Yu/LaTeX-Workshop/issues/1245#issuecomment-475875104