Hans Hagen scripsit (02.09.2008 10:09)

can you try the table call, like in

os.exec({"c:\\Program Files\\Adobe\\Reader 9.0\\Reader\\acrord32.exe","e:/tmp/oeps.pdf"})

I did try the table call (that's actually the form used in the original script where the problem first appeared).

here both spawn and exec seem to work ok

Do you mean you tried the above example with Adobe Reader 9 on windows and AR did not crash? Here (win XP SP2, AR9, LuaTeX 0.25.4 from TL'08) it crashes, and the original scripts from which I extracted the minimal demo above have been reported to crash on: - Vista + Adobe Acrobat pro 9 (TL'08) - Unkown windows (I can ask) + Adobe Reader 8.1 (TL'08) (dump available) Up to now the problem looks rather reproducible. I would be rather surprised that you can't reproduce it.

btw, there is 'pdfopen' for opening pdf files; if the operating system supports suffix associations os.execute("e:/tmp/oeps.pdf") works too

On windows I was originally using 'start' to open any file using suffix associations. I changed it to acrord32 just for this example to make it clear the problem was with AR9 and not with the association mechanism or whatever. Manuel.

Hans Hagen a écrit :

i tried your script

You mean scriptS? Because the problem happens only when there are two scripts involved. I did another round of tests, systematically trying all combinations of os.execute, os.exec, os.spawn, with both string and list form for exec and spawn. The result is rather clear: the crash happens if and only if the wrapper invokes os.exec() or os.spawn() (any form). Reformulating: it works if and only if the wrapper invokes os.execute.

on vista (ultimate, sp 2) and had no crash;

I'll try to find other machines to run more tests.

actually acrobat didn't start unless i provide the full path

As I said, I previously added acrobat to my path to simplify the tests.

os.exec({"c:\\Program Files\\Adobe\\Reader 9.0\\Reader\\acrord32.exe","e:/tmp/oeps.pdf"})

opens the file but with an acrobat message (file not found while the file is opened anyway) so the problems you report might be with acrobat

It does the same on my machine, invoked this way. Interestingly enough, it stops doing so if I add c:\Program Files\Adobe\Reader 9.0\Reader to my PATH and then call just os.exec {"acrord32", "d:/pathto/file.pdf"}. Anyway, this is not the problem. The problem is that when you call in any way (os.execute, os.exec, os.spawn) AR9 froms a texlua script that was os.spawn()-ed or os.exec()-ed by a texlua script that previoulsy initialised kpse, it crashes. Probably there is something specific to acrobat reader version 8 and 9, but it doesn't look totally unrelated to os.exec() or os.spawn() either... Manuel.

Hans Hagen a écrit :

Manuel Pégourié-Gonnard wrote:

...

You mean scriptS? Because the problem happens only when there are two scripts involved.

the two scripts (but using other paths)

Could it be that your newer version of LuaTex explains that it works for you and fails for the other people who reported problems?

...

Anyway, this is not the problem. The problem is that when you call in any way (os.execute, os.exec, os.spawn) AR9 froms a texlua script that was os.spawn()-ed or os.exec()-ed by a texlua script that previoulsy initialised kpse, it crashes. Probably there is something specific to acrobat reader version 8 and 9, but it doesn't look totally unrelated to os.exec() or os.spawn() either...

could be some interaction indeed (maybe in intercepting the return values or so), print(os.spawn(...))

Do you need more info from my failing system to investigate? If so, please tell me what you need. Manuel.