Closed GauSyu closed 5 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.
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
This issue has been marked as stale because due to inactivity. It will be closed in 7 days if no further activity occurs.
@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).
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
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.
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).
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.
Same for me (Windows 10 / texlive). Anyone knows how to fix?
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 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.
@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.
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:
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?
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
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.
@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.
@scrouthtv I can try but it used to work just fine (until a recent Atom and/or latexmk update).
@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).
@Aerijo Sure, I will try that on Monday. Luckily, I am only running Windows on my work computer.
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
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.
@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.
@Aerijo That’s true, but I kinda did that for vscode compatibility, since the developer has no plan for such accommodation.
The author agreed to make changes to the code. From now on, by adding -cd
option, the directory can have the weird characters.
@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.
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.
@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.
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
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:
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).