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

Errors when compiling from another directory #1393

Open
jperon opened this issue Dec 4, 2017 · 16 comments · Fixed by #1543
Open

Errors when compiling from another directory #1393

jperon opened this issue Dec 4, 2017 · 16 comments · Fixed by #1543

Comments

@jperon
Copy link
Contributor

jperon commented Dec 4, 2017

Here's an example: if I am in the /home/user folder, then compile the gabc. tex document that is in /tmp/test: lualatex -shell-escape -output-directory=/tmp/test /tmp/test/gabc.tex

  • if this document contains a command \gregorioscore, I get the error The file gabc-score.gabc does not exist;
  • if it contains a command \gabcsnippet, the message obtained is error: kpse prohibits write to file /tmp/test/gabc.gtmp.

I could of course chdir into the document's folder, but I encounter this problem in trying to develop a filter for pandoc, and pandoc doesn't chdir before calling lualatex.

Here is a MWE to test:

\documentclass{article}
\usepackage[autocompile]{gregoriotex}
\begin{document}
\gabcsnippet{(c4) A(f)ve.(c)}
\gregorioscore{gabc-score}
\end{document}
@rpspringuel
Copy link
Contributor

rpspringuel commented Dec 4, 2017 via email

@jperon
Copy link
Contributor Author

jperon commented Dec 4, 2017

I can confirm that, when setting the environment variable openout_any=a, the first error disappears ; the second doesn't with the MWE, but as pandoc "stays" in the original folder, it finds the score. So as is, it works.

Just in case ; wouldn't it be possible to detect when kpse prohibits to write to output-directory, and then default to a subfolder of current directory (that would be writeable) to avoid failing compilation ?

@rpspringuel
Copy link
Contributor

rpspringuel commented Dec 4, 2017 via email

@jperon
Copy link
Contributor Author

jperon commented Dec 4, 2017

My mistake, excuse me : the second error disappeared, not the first. You understood well !

@rpspringuel
Copy link
Contributor

rpspringuel commented Dec 5, 2017 via email

@jperon
Copy link
Contributor Author

jperon commented Dec 5, 2017

I think so ; on the other hand, shouldn't this behaviour be considered as a Kpathsea bug ? The output directory isn't an arbitrary one, as the user explicitly indicates it as a target. In that case, I could report it upstream (even if I don't know where).

@rpspringuel
Copy link
Contributor

rpspringuel commented Dec 5, 2017 via email

@jperon
Copy link
Contributor Author

jperon commented Dec 5, 2017

The problem doesn't occur while writing directly from lua code.

Now I remember the problem had already occured when \gabcsnippet was introduced, hence PR #494. But since the compilation of gabc scores now makes use of temporary files (.gaux), the process was reverted.

So I think the real problem comes from how gregorio detects wether kpathsea allows writing or not (probably the kpathsea_out_name_ok_silent test in src/support.c line 151). Then the problem would come from source/texk/kpathsea/tex-file.c in luatex source ; but with my knowledge in C, I can't tell anything more…

@rpspringuel
Copy link
Contributor

I've come across this error in some of my own work and that has spurred me to think about a possible solution.

One thing I've come up with is the possibility of creating a GregorioTeX specific working directory in a place which kpathsea does permit writing (like the current directory). All gtex and glog files would go into this folder. We could also use it for snippets if we ever implement the feature to keep gtex files for debugging (#1206).

Does anyone have any thoughts on this idea?

@Nokel81
Copy link

Nokel81 commented Mar 4, 2020

I have found that this is a problem when trying to use the subfiles package.

@rpspringuel rpspringuel mentioned this issue May 21, 2021
@MaestroGlanz
Copy link

I have the same problem. I have also problems adding the openout_any=a variable. I tried adding it to the LuaLaTeX call and also to the current shell. Neither works.
I have 290 files in the directory. After compiling, this will be 870 files. For obvious reasons, I don't want to move them to the cwd.
The protection from kpse is a nanny feature and shouldn't exist. But this is my own opinion about such things. A knife is also safer, when it is not sharp.

I couldn't figure out, how to add the variable, but I suppose, that someone of you knows, how to do it.

@rpspringuel rpspringuel linked a pull request Oct 10, 2023 that will close this issue
@Josh-Nehnevaj
Copy link

I'm having the kpse error when trying to access a .gabc file in a separate directory. I cannot figure how to modify the environment variables and add openout_any=a. I feel like I'm missing some very basic step to modify the environment variable, but I can just not figure it out. Any help you can offer is greatly appreciated.

@rpspringuel
Copy link
Contributor

@Josh-Nehnevaj, please try #1543. That change should negate this problem.

@Josh-Nehnevaj
Copy link

@rpspringuel , That made some progress, in that I'm no loner getting the kpse error, but now the only thing that renders is the horizontal lines for the staff and the clef, a line below where it should be. When I place a copy of the .gabc file in the same folder as the .tex file everything appears as it should.

@rpspringuel
Copy link
Contributor

That doesn't make sense. Can you create a simple project with the appropriate directory structure to demonstrate the error, zip it up, and upload it here.

@Josh-Nehnevaj
Copy link

This still makes no sense to me, but it looks like I was missing a ";" in my header. I was having trouble recreating the problem in a test folder unless I used the exact same files from the main project. When I added a ";" at the end of the final header line, it solved the problem in both the main project and the test project. Thanks for your patience.

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

Successfully merging a pull request may close this issue.

5 participants