On 01/01/2012 7:08 PM, Bogdan wrote:
As part of my course, I've been traditionally maintaining a problem sheet in latex and compile two versions, one with answers, and one without. To achieve that, I hide the answers based on whether a certain variable was defined in latex or not and then compile it accordingly:with answers: pdflatex sheet.tex without answers: pdflatex "\def\noanswers{yes}\input{sheet.tex}" I defined a new converter in LyX do achieve the same but I could not do it without wrapping the 2nd command in a shell script (I'm using windows). What I did: - defined a new file format pdf6: PDF (pdflatex-na) with the same settings as pdf2: PDF (pdflatex). - defined a converter Latex (pdflatex) -> PDF (pdflatex-na) with the following for converter: pdflatex "\def\noanswers{yes}\input{$$i}" Checking the lyx preferences file, I see it correctly escaped as: \converter "pdflatex" "pdf6" "pdflatex \"\\def\\noanswers{yes}\\input{$$i}\"" "latex=pdflatex" However, when I try to use it (update or export) then LyX launches the converter and keeps waiting for it to terminate. Investigating the matter with a task manager like Process Hacker or Process Explorer, in order to see what command was actually executed, I notice that LyX started a cmd shell which in fact executed the following: pdflatex "\def\noanswers{yes}\input{ }" sheet.tex Note the empty \input{} and the file name sheet.tex at the end, instead of inside \input{sheet.tex}. I tried with the other variables $$b.tex, $$p, $$r etc, to no avail. Unless I'm missing something, this looks like a bug. Is there a python script anywhere that launches the cmd shell? It's probably there and I could fix it. My workaround is to wrap the whole thing in a cmd script pdflatexna.bat placed in lyx/bin with the contents: @pdflatex "\def\noanswers{yes}\input{%~1}" (the %~1 instead of %1 is to strip any double quotes) .... and then use the following command for the converter: pdflatexna $$i Cheers, Bogdan.
Yes in the case of a converter with a latex flag, $$i is replaced by an empty string and the input file is added at the end of the command line. I wondered why this is like this and I can't see a reason besides that it must have been this way before the introduction of the $$i token. It is unintuitive for users and should be made consistent.
-- Julien
