I'm not quite sure if this is a bug or a configuration problem yet. If I can get confirmation from others that it is a problem I will file a bug report.

I installed the recently updated texosquery (v 1.2.1). After getting everything going, I find that running texosquery from the command line is fine and running it via \write18 prints to the log/console without problems. Therefore, I know the --shell-escape option is valid.

The problem comes when I actually try to use texosquery in XeLaTeX or XeTeX. pdfLaTeX seems to work fine, but I think it defaults to using the \pdf... primitives, in this case.

System details:

  • Windows 10
  • MiKTeX 2.9.6210 64-bit
  • texosquery 1.2.1
  • MiKTeX-XeTeX 2.9.6216 (0.99996)
  • (let me know if anything relevant is important)

With or without debugging, all the macros returned from \TeXOSQuery are empty/blank in the PDF generated by XeLaTeX.

For example with \TeXOSQuery{\result}{--debug --locale}\result I see the output via \write18 in the log/console but it's not getting into the PDF.


% arara: xelatex: {shell: on}



    %returns correct details and log/console output:
    %\pdfd \fcln 20170330184224\fpls 11\fapo 00\fapo
    \immediate\write18{texosquery-jre8 --debug --pdfnow} 

    %empty output
    \TeXOSQuery{\result}{--debug --pdfnow}\result 

    %prints "HERE IS RESULT: " to log/console
    \immediate\write18{echo HERE IS RESULT: \result}

    %no PDF is created after successful compilation


Compiled via (miktex-xelatex and xelatex give same results):

miktex-xelatex.exe -enable-enctex -enable-etex -enable-mltex -enable-pipes -enable-write18 -synctex=1 --shell-escape "test-xeltx2.tex"

I wasn't sure how else to troubleshoot the issue. I'm hoping to tease apart an installation problem, a configuration problem, or a bug. If a bug, is it possible to find a workaround for this?

EDIT: Forgot to include the config info for MiKTeX and texosquery.

In texapp.ini, the relevant info:


;; Commands allowed via partially enabled \write18{...}.

And in texosquery.cfg:



Hope that helps!

EDIT2: I conflated two different issues. I am moving the error/permissions issue here and will keep the non-error issue above. This error occurs from the command line also, so it appears to be unrelated to XeLaTeX, but rather MiKTeX permissions (I think?).

Turning on debugging, for example with texosquery --debug --cwd I get the following error (path edited for privacy):

texosquery-jre8: Can't determine openin value, assuming 'p'
texosquery-jre8: "kpsewhich '-var-value=openin_any'" failed with exit code: 1
java.io.IOException: "kpsewhich '-var-value=openin_any'" failed with exit code: 1
    at com.dickimawbooks.texosquery.TeXOSQuery.kpsewhich(TeXOSQuery.java:135)
    at com.dickimawbooks.texosquery.TeXOSQuery.isReadPermitted(TeXOSQuery.java:312)
    at com.dickimawbooks.texosquery.TeXOSQuery.getCwd(TeXOSQuery.java:960)
    at com.dickimawbooks.texosquery.TeXOSQuery$2.action(TeXOSQuery.java:4033)
    at com.dickimawbooks.texosquery.QueryAction.doAction(QueryAction.java:367)
    at com.dickimawbooks.texosquery.TeXOSQuery.processArgs(TeXOSQuery.java:4002)
    at com.dickimawbooks.texosquery.TeXOSQueryJRE8.main(TeXOSQueryJRE8.java:369)
texosquery-jre8: Read access forbidden by openin_any=p (has absolute path outside TEXMFOUTPUT): C:\PATH\tests
texosquery-jre8: Read access not permitted for the current directory

It seems there are two problems here. First, MiKTeX is not using texmf.cnf, common in other installations. This may not be a problem if kpsewhich looks inside the file contents...except I've tested it with variables that are in the .ini files of MiKTeX (default: C:\Program Files\MiKTeX 2.9\miktex\config) and also with filenames. kpsewhich doesn't seem to be allowed in that folder, even for viewing/read rights (or I'm doing it incorrectly).

Just for fun, I created a texmf.cnf with the line openin_any=a. I put it in the installation (admin) config folder, the local (user) config folder, and also in the installation (admin) root folder. I refreshed FNDB for admin and user each time, to be safe. No change of behavior.

When running kpsewhich -var-value=openin_any in the command line, nothing changes. If I add openin_any to the local user variables with a value a, this does show up with the command. However, this variable/value doesn't seem to be recognized via texosquery-kpsewhich still.


MiKTeX has a different kpathsea/kpsewhich implementation and openin_any isn't defined there. But you can add the variable as a environment variable. This here got rid for me of the kpsewhich error:

C:\Users\XXX\Documents\tests>set openin_any=a

C:\Users\XXX\Documents\tests>pdflatex --shell-escape --enable-pipes test-utf8

As miktex has a texorquery.exe in its bin folder I removed the jre8 references from your example. I didn't change or add any configuration files, but used simply the state as I got it from miktex NEXT. I do have java 1.8 and this seems to be the default for texorquery.





    %returns correct details and outputs to log/console
    \immediate\write18{texosquery --debug --pdfnow}

    %empty output, produces the error above via log/console - but doesn't halt compilation
    \TeXOSQuery{\result}{--debug --cwd}\result

    %prints "HERE IS RESULT: " to log/console
    \immediate\write18{echo HERE IS RESULT: \result}


Sadly this didn't got rid of a second problem: miktex seems not to correctly handle commands with argument in a pipe. This can be seen with such a document (compile with xelatex or pdflatex --enable-pipes):

\@@input|"kpsewhich --help"

% \@@input|"dir"  %works

I made a bug report about this problem: https://sourceforge.net/p/miktex/bugs/2589/ With lualatex --shell-escape your example compiles fine (no --enable-pipes needed).

  • Ah, thank you for the details. I hadn't thought about setting the variable that way because I thought it needed to read a file for it. This does fix the permissions issue (e.g. using --cwd) for me. Unfortunately, if I understand you correctly, this means texosquery is effectively unusable under the MiKTeX version of XeLaTeX until the pipe issue is resolved. What I am a bit confused about is that pdfLaTeX compiles the same document with --enable-pipes for me without any issues.
    – whatisit
    Mar 30 '17 at 12:12
  • I have miktex NEXT and there both pdflatex and xelatex are broken. In the standard miktex on my other PC only xelatex is affected. But Christian already answered to my bug report so I think that the issue will be resolved fast. Mar 30 '17 at 12:22
  • I see. That clarifies things. I marked this as the answer because it responds to both issues; the bug, it seems, will be resolved in the near future by Christian. On the openin_any issue, I opened up a new issue on github (see 'openin_any' is not available for MiKTeX (Window) users). I hate to ask for an installation-specific request, but I think this has the potential to affect many TeX users otherwise.
    – whatisit
    Mar 30 '17 at 23:46
  • You could also add a feature request for miktex that its kpsewhich "broadcast" openin_any. Mar 31 '17 at 7:37
  • Good point. I posed the question to Nicola over on the github issue to see which option is a best long term solution. Thanks for the explanations and suggestions.
    – whatisit
    Apr 1 '17 at 2:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.