-
Notifications
You must be signed in to change notification settings - Fork 45
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
Redirection warning #1628
Comments
Quoting Akira's messages for reference:
Second message:
|
Since I want to keep the ability to capture that kpsewhich error which started this whole thing, Akira's patch (which just reverts to what we had before) is the solution. We need something more complicated. Perhaps we should only add the redirection argument when we discover we're not in restricted mode? I'm not sure how to detect that directly in Lua, but this StackExchange question provides an engine agnostic way of doing the detection which we could adapt to set an internal flag that Lua could read. Akira also pointed out that our creativity in re-using the glog file for both this error redirection catch and the regular error logging that the executable does creates a problem for ltluatex.lua, so perhaps we need to simply create another file for catching this error. |
Since the redirection doesn't work in restricted mode, we only add it when `--shell-escape` has been given. Further, rather than reusing the glog file, we create a special file for capturing the redirection error. This addresses gregorio-project#1628.
What if gregorio prints to stdout until it successfully opens the log file? Then luatex can capture stdout (using io.popen). |
I don't think that will work, the error we're trying to capture here isn't one that we try to write ourselves, but rather one which gregorio kind of "inherits" from the kpathsea libraries (it only appears when gregorio is compiled with those libraries). You're welcome to try and play with it, but my sense of this is that kpathsea is responsible for forcing this error to stderr, and that's why it bypasses our normal logging and requires this kind of slight of hand. |
The error that (I thought) was in question is printed here: Lines 154 to 155 in ec7c886
But I see that gregorio has an option to write the gtex file to stdout, so writing errors to stdout is not a good idea. (On the other other hand, there are several error messages, like the license and usage, that are printed to stdout already.) |
I think that is the error (the C code is not my specialty), but you'll note that we're already using If you can find a way to get the message into the glog file without redirection, that would be great. I don't like the idea of having a log file specifically for this one error message, I just don't know how to do it otherwise at this point. |
Here's what I see in the develop branch:
So the original error in question does get redirected correctly. If we do the same thing again, we want it to append, not overwrite:
That looks good again. The only error that has to go to stderr is of course if the glog file itself is not writable:
I believe it's in this one case that the new .glog.err file will be non-empty in shell-escape mode, and it's in this one case that the error would be lost in restricted \write18 mode. My suggestion above was to send this one error to stdout so that the Lua code can capture it, but I no longer think that's a good idea and don't have a better idea. Maybe the Lua code can write the .glog.err file into the .glog file and then remove the .glog.err file. |
That doesn't match what I recall, but it's been several years since we looked at this so it might be that my memory is mistaken. @davidweichiang, have you checked what happens when a gregorio call that would trigger this error happens in a TeX document? |
If I do the following, using branch
Then the run pauses with an error, and after continuing, I see
I'm not seeing why the |
It creates the |
Another small issue is that both the C and Lua code append to the glog file, and neither ever clears it. So in theory it will keep getting longer and longer. |
@davidweichiang, based on your testing, it seems that it may no longer be possible for errors to end up in stderr and not our glog file. If that's the case, then we can get rid of the redirection altogether. Unfortunately I've lost my tester files for this error, so I can't quickly confirm this behavior on my end.
As I understand it, kpse requires files to be written to the current working directory (or subdirectories thereof). It prohibits writing to parent directories (or subdirectories thereof that aren't the current directory or subdirectories thereof). I would like the glog file to always end up in a tmp-gre folder even when someone's playing shenanigans with where they're calling luatex from. I'm not sure why the tmp-gre folder is not being created in your toy example.
The glog file should probably be regenerated whenever the gtex file is regenerated. |
Yes, that's how it looks to me, with the sole exception of not being able to open the glog file itself. This happened in commit 8ec1d64.
Sorry I wasn't clear. The Lua code (function But if a gtex file is found -- anywhere in TEXINPUTS -- the glog file is just in the same directory as the gabc file: Line 1263 in ba5c432
It gets more complicated if the user does either lualatex path/to/file.tex or \gregorioscore{path/to/file.gabc} ; I wasn't able to untangle all the cases.
Agreed, and that should be a one-line fix. Line 378 in ba5c432
|
Ah! Now I get what's going on. This was to preserve backwards compatibility with files compiled before I don't remember off-hand if there were other errors that went into the glog file (and thus necessitated the append mode). Was this stderr redirect the only thing that would get written to the glog file besides what the executable wrote? If so, then yes, we can revert to opening in write mode rather than append mode. |
Yes, a search for |
PR #1632 tries to fix all of the above issues. The third commit is kind of big and I'll leave a few comments over there. |
The warning about ignored arguments reared its head with Akira Kakuto in his testing and it bothered him enough that he emailed me a bug report (with a patch that removes the redirection). Perhaps we need to reassess just how "harmless" this warning is and see if there isn't something we can do about it while still leaving open the option of capturing the error it's meant to capture.
Refer to #1541 and #1606 for past discussion.
The text was updated successfully, but these errors were encountered: