Call to xindy failed due to double path on windows

Question

I have a problem with makeglossaries after installing MikTex on my windows10 machine. pdflatex and biber work perfectly fine, yet when calling makeglossaries it fails with the following error message:

$makeglossaries Main
makeglossaries version 4.36 (2018-03-07)
added glossary type 'main' (glg,gls,glo)
xindy  -L english -C duden-utf8 -I xindy -M "Main" -t "Main.glg" -o "Main.gls" "                                                                       Main.glo"
/d/local/thesis/C:/Program Files/MiKTeX2.9/scripts/xindy/../../xindy                                                                       /modules: No such file or directory at C:\Program Files\MiKTeX2.9\scripts\xindy\                                                                       xindy.pl line 402.

***Call to xindy failed***

Check 'Main.glg' for details

I checked out wolfie's Answer but find that this was already implemented in the xindy script.

The error seems to be that the path is concatenated in the $real_cmd variable in the script on line 372.

Any ideas on how to fix this?

Here is a striped down version of my latex setup:

Main.tex:

\documentclass[
 11pt,              
   english,
   a4paper,           
   DIV=11,            
   listof=numbered,
]{scrreprt}

% -------------------------------------------------------------------------
\setlength{\parskip}{0.75em}   
\usepackage{geometry}          
\geometry{bindingoffset=0.5cm,hmarginratio=3:4, bottom=4.5cm}

\widowpenalty10000          
\clubpenalty10000

%---- PACKAGES ----
%\usepackage{hyperref}      
\usepackage[hidelinks]{hyperref}    

\usepackage[utf8]{inputenc} 
\usepackage[english]{babel} 

\usepackage[T1]{fontenc}    
\usepackage{textcomp}       
\usepackage{lmodern}        
\usepackage{pdfpages}       
\pdfminorversion=7          
\usepackage{graphicx}       

\usepackage{tabularx}      
\usepackage{hhline}         
\renewcommand\arraystretch{1.1} 
\makeatletter               
\newcommand{\thickhline}{
    \noalign {\ifnum 0=`}\fi \hrule height 1pt
    \futurelet \reserved@a \@xhline
}
\makeatother

\def\hyph{-\penalty0\hskip0pt\relax}    

\usepackage{xcolor}     

\definecolor{bostonuniversityred}{rgb}{0.8, 0.0, 0.0}

% This is the interesting part I guess -------------------------------
\usepackage[section=section,numberedsection=autolabel,toc,nonumberlist,xindy]{glossaries}
\GlsSetXdyCodePage{duden-utf8}
\makeglossaries     
\input{glossary.tex}    
% ----------------------------------------------------------------- 

\usepackage[chapter]{minted}        
\usepackage{scrhack} 
\usepackage{listings}

\renewcommand{\listingscaption}{Code Snippets}
\renewcommand{\listoflistingscaption}{List of Code Snippet}


\usepackage[german=quotes]{csquotes}        
\MakeOuterQuote{"}

%---- BIBLIOGRAPHY ---
\usepackage[block=ragged,backend=biber,bibstyle=ieee]{biblatex}     
\addbibresource{Bibliography.bib}

\makeatletter
\def\blx@maxline{77}
\makeatother


\begin{document}

         \gls{someEntry} 
         \gls{someEntry2} 

    \newpage
    \printglossary[title=Glossary]
\end{document}

glossary.tex:

\newglossaryentry{someEntry}{
    name={Some Entry},
    description={Some Description}
}
\newglossaryentry{someEntry2}{
    name={Some Entry 2},
    description={Some Description 2}
}

In the resulting pdf File the name is visible, so it read the glossary file correctly, but was not able to print it due to the makeglossaries command failing.

Hi, and thanks. Do you mean a examplenary template? I could add that. — CyrillC, Mar 13 '18 at 22:08
As a temporary solution try makeglossaries -x "C:/Program Files/MiKTeX2.9/scripts/xindy" Main (replace C:/Program Files/MiKTeX2.9/scripts/xindy with the appropriate path) — Nicola Talbot, Mar 13 '18 at 22:13
@NicolaTalbot This does not seem to work, but I might missunderstood you. the path should be pointing to the xindy.pl file right? If I add the file to the path, then I get an error due to some linking issue, and if I remove the specific filename and leave the path to the directroy, it fails due to the path beeing a directory. — CyrillC, Mar 13 '18 at 22:35
@CyrillC It might be called makeglossaries-lite.lua. It should be located in the same directory as makeglossaries.exe. Alternatively you can fetch it from CTAN. — Nicola Talbot, Mar 14 '18 at 13:44
@NicolaTalbot Neither works, the output of makeglossaries -n Main is
makeglossaries version 4.36 (2018-03-07) added glossary type 'main' (glg,gls,glo) xindy -L english -C duden-utf8 -I xindy -M "Main" -t "Main.glg" -o "Main.gls" "Main.glo" — CyrillC, Mar 22 '18 at 21:31
I will have a look a gendoftest's answer, yet I believe you are more capable of deciding if this would be something to implement =) — CyrillC, Mar 22 '18 at 21:33
@CyrillC The -n switch just displays the version and shows how it would invoke xindy/makeindex without actually doing anything. I just wanted to check if there was a problem with the way that makeglossaries is invoking xindy. From your comment it seems to be invoking xindy correctly, in which case the problem is with xindy. — Nicola Talbot, Mar 22 '18 at 22:30

score 2 · Accepted Answer · answered Mar 21 '18 at 20:10

I digged a bit deeper and found a partial solution. Since I don't have enough karma yet, I cannot post this as comments though (and I am not sure it would be the right way).

xindy.pl line 372 reads:

our $real_cmd = Cwd::realpath($0);

If I add

print "real_cmd: $real_cmd\n";

after that, it prints

real_cmd: /c/Users/username/Desktop/TeX/auxdir/C:/Program Files/MiKTeX 2.9/scripts/xindy/xindy.pl

which is wrong.

Putting these lines into a test file named test_Cwd.pl:

#!/usr/bin/perl -w
use Cwd;
our $real_cmd = Cwd::realpath($0);
print "real_cmd: $real_cmd\n";

Output with windows paths:

$ C:\\Users\\username\\Desktop\\test_Cwd.pl
real_cmd: /c/Users/username/Desktop/C:/Users/username/Desktop/test_Cwd.pl

Output with emulated unix paths on Windows:

$ /c/Users/username/Desktop/test_Cwd.pl
real_cmd: /c/Users/username/Desktop/test_Cwd.pl

This difference in behavior of perl is know and described in https://stackoverflow.com/a/46773471.

Possible solutions:

Fix C:\Program Files\MiKTeX 2.9\miktex\bin\x64\xindy.exe to execute perl with /c/Program\ Files/MiKTeX\ 2.9/scripts/xindy/xindy.pl on msys. I don't know how to do this as I am unable to find the package providing xindy.exe.
Fix C:/Program Files/MiKTeX 2.9/scripts/xindy/xindy.pl to convert the Windows-style path to a Unix-style path (dirty hack, done below)
Fix the perl interpreter's Cwd package to convert Windows-style paths to Unix-style paths (general solution, may break other code)

Msys and Cygwin also have the cygpath utility which does help creating a workaround:

You'll need to fix platform detection in xindy.pl first, see https://sourceforge.net/p/xindy/feature-requests/47/.

Then replace xindy.pl line 372, which looks like this

our $real_cmd = Cwd::realpath($0);

by

our $real_cmd = "";
if ( $is_w32 ) {
    our $cygpath_cmdline = "cygpath \"$0\"";
    our $unixified_cmd_path = `$cygpath_cmdline`;
    $unixified_cmd_path =~ s/\r//g;
    $unixified_cmd_path =~ s/\n//g;
    our $real_cmd = Cwd::realpath($unixified_cmd_path);
} else {
    our $real_cmd = Cwd::realpath($0);
}

But then xindy-lisp.exe will fail reading the tempdir filename:

*** - PARSE-NAMESTRING: syntax error in filename
  "\"/c/Users/username/Desktop/TeX/auxdir/FVWzOBrFBF\"" at position 0

This file does exist, but xindy-lisp.exe seems to expect the filename without \" but with single double quotes instead. Manually editing the commandline and removing \" gets me further. When parsing the temporary file and reading other paths from there, it fails again.

I am using perl from git-bash (msys, 64Bit) with MiKTeX 64Bit on Windows 7. All software is updated to its latest version afaik, except maybe perl.

$ perl --version

This is perl 5, version 26, subversion 1 (v5.26.1) built for x86_64- 
msys-thread-multi

PS: my perl code may be bad style as I am new to perl. Suggestions are welcome!

Call to xindy failed due to double path on windows

1 Answers1