3

I noticed that recently, when I launch texindy using the shortkey in TeXstudio F12 it throws an error:

Process started: texindy.exe

usage: texindy.pl [-V?h] [-qv] [-iglr] [-d magic] [-o outfile.ind] [-t log] \ [-L lang] [-C codepage] [-M module] [-I input] [idx0 idx1 ...] GNU-STYLE LONG OPTIONS FOR SHORT OPTIONS: -V / --version -? / -h / --help -q / --quiet -v / --verbose -i / --stdin -g / --german -l / --letter-ordering -r / --no-ranges -d / --debug (multiple times) (supported: script, keep_tmpfiles, markup, level=n) -o / --out-file -t / --log-file -L / --language -C / --codepage -M / --module (multiple times) -I / --input-markup (supported: latex, omega) C:\texlive\2013\bin\win32\runscript.tlu:650: command failed with exit code 1: perl.exe c:/texlive/2013/texmf-dist/scripts/xindy/texindy.pl

Process exited with error(s)  

Below is a screenshot of texindy configuration in TeXstudio:
enter image description here

When I use arara to compile there is no problem with xindy, here is the arara code:

% arara: xelatex: { shell: true }
% arara: makeglossaries
% arara: biber
% arara: xelatex: { shell: true }   
% arara: xelatex: { shell: true } 

This is an excerpt from arara log file.txt regarding xindy:

added glossary type 'main' (glg,gls,glo)
xindy  -L english -C utf8 -I xindy -M "phdmain" -t "phdmain.glg" -o "phdmain.gls" "phdmain.glo"
Opening logfile "phdmain.glg" (done)
Reading indexstyle...
Loading module "iaheC42kMp"...
Loading module "lang/english/utf8-lang.xdy"...
Loading module "lang/english/utf8.xdy"...
Finished loading module "lang/english/utf8.xdy".
Finished loading module "lang/english/utf8-lang.xdy".
Loading module "phdmain.xdy"...
Loading module "tex.xdy"...
Finished loading module "tex.xdy".
Finished loading module "phdmain.xdy".
Finished loading module "iaheC42kMp".
Finished reading indexstyle.
Finalizing indexstyle... (done)

This is an excerpt from the running messages while compiling the document successfully using arara:

Status: SUCCESS

Running MakeGlossaries...

makeglossaries version 2.07 (2013-06-17)
added glossary type 'main' (glg,gls,glo)
xindy  -L english -C utf8 -I xindy -M "phdmain" -t "phdmain.glg" -o "phdmain.gls" "phdmain.glo"

Opening logfile "phdmain.glg" (done)
Reading indexstyle...
Loading module "iaheC42kMp"...
Loading module "lang/english/utf8-lang.xdy"...
Loading module "lang/english/utf8.xdy"...
Finished loading module "lang/english/utf8.xdy".
Finished loading module "lang/english/utf8-lang.xdy".
Loading module "phdmain.xdy"...
Loading module "tex.xdy"...
Finished loading module "tex.xdy".
Finished loading module "phdmain.xdy".
Finished loading module "iaheC42kMp".
Finished reading indexstyle.
Finalizing indexstyle... (done)

Reading raw-index "oxOB1i9YoU"...
Finished reading raw-index.

Processing index... [10%] [20%] [30%] [40%] [50%] [60%] [70%] [80%] [90%] [100%]
Finished processing index.

But as I said when I invoke xindy alone it throws the error mentioned in the beginning of the question.

So what am I missing here? how to fix this error?

Note:
TeXstudio version: 2.6.4
Xindy version: 2.4
Distribution TexLive2013

1

Though you did not show the relevant screenshot, I am quite sure the issue is a change sometimes occurring for unknown reasons. At least this happened here in a portable TeXstudio, and a user in Germen usenet group de.comp.text.tex complained about this, too:

In menu “Options” —> "Configure TeXstudio” —> “Commands” the entry for Texindy lacked the parameter. Therefore changing this to

texindy.exe %.idx

should bring the function back to you.

Cf. a screenshot made by Harish Kumar for another question (Has anyone managed to use \glossaries with TeXstudio on Windows?, because of this makeglossaries.exe is marked):

screenshot of TeXstudio configuration

You should control the marked makeglossaries.exe, as well, because this was also affected by this strange phenomenon/bug.


Harish and me have BTW compared our versions (“About TeXstudio”) and we seem to have the same, but he has the installation variant and I as said above the portable one.

  • +1, for the careful answer, indeed, fixed the problem. My guess this would also fix a strange behavior that I used to live with, that gls{} sometimes does not abbreviate the acronym but would typeset as if firstly used, so I had to pass glstext{} to force that. – doctorate Feb 10 '14 at 7:42

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.