[tex-live] texlive perl

[T T]

On 21 April 2010 22:32, Reinhard Kotucha <reinhard.kotucha at web.de> wrote:
> On 21 April 2010 T T wrote:
>  >
>  > The problem seems to be with Perl.  I can't start AR9 from Perl at
>  > all, always the same error as you see.  What's even more bizarre, I
>  > can't start AR9 from any child process started from Perl!  So there
>  > is something that is inherited from the perl.exe process that
>  > causes AR to crash, but I have no clue what it might be and I
>  > couldn't find anything suspicius in Perl's sources regarding
>  > process spawning.  I'm out of ideas I'm afraid.
>
> It's probably not Perl specific.  We encountered the same problem with
> the texlua wrapper for texdoc.  We first assumed that the argument
> vector had not been passed properly to AR.  I then read all the
> related mails again carefully and found an interesting hint: The error
> doesn't occur when AR is already running.  This means that the
> argument vector can't be the culprit.  On the other hand, Manuel found
> out that it made a difference whether the wrapper passed the arguments
> as a list (os.spawn()) or as a string (os.execute()).

You're right. As Manuel pointed out it seems to happen only if texlua
wrappers are used.  I will do more testing tomorrow.

> os.execute() is a Lua function which expects a string as an argument
> and calls system(3) in order pass the request to a shell.  os.spawn()
> is a function gratefully provided by Taco.  It passes its arguments as
> a list to execvpe(3).
>
> The Perl function system() also supports both, system(3) and
> execvpe(3).  However, Perl tries to be smart, which makes debugging a
> bit harder.  If you provide a string, system() always passes the
> string to a shell.  If you provide a list, Perl decides itself whether
> system(3) or execvpe(3) is more appropriate.

Yes, I'm quite familiar by now how those things work in texlua and
perl.  Still, I'm really baffled how those problems can propagate
farther down to child processes.  I started cmd.exe from perl that was
spawned from texlua and AR9 just wouldn't run from that cmd.exe no
matter what (nor from any other process started from there).

> On Unix, execvpe() simply passes the argument list to the program it
> executes.  On Windows, however, it converts the list to a string and
> then the string back to a list again.  Of course, this breaks
> arguments containing space characters.  The workaround is to quote
> each argument.
>
> The difference between Perl and texlua is that Perl automatically
> quotes all arguments before they are passed to execvpe(3) while in
> texlua you have to quote arguments yourself.  Under Windows at least.

This is definitely not the quoting problem.  I always pay special
attention to this, because this is such a PITA on Windows.

> If you can reproduce the problem with texlua, I think that debugging
> is much easier because Lua is tiny.
>
> However, I suppose that it's a Windows problem, quite unrelated to
> Perl or texlua.  How execvpe() is implemented under Windows is
> completely braindead and error-prone.

Indeed, the spawn* and exec* functions on Windows are absolutely
braindead to the point that makes you wonder whether they aren't
broken on purpose.

Anyway, if the problem is indeed related to os.spawn() in texlua, then
at least I know where to look.  I did patch that function not so long
ago, so I will try with the recent texlua build as well and see if
there's any difference.

> Another approach is to ask Adobe under which circumstances the error
> message "Internal Error" is raised.  It's probably difficult to get in
> contact with Adobe developers.  But you could ask Leonard Rosenthol.
> I remember him as a maintainer of the PDF backend of ImageMagick but
> for 3 or 4 years he is employed by Adobe as a PDF guru.  He's quite
> open to TeX-related problems.

Let's wait with bothering 3rd parties until we exhaust other options.
But I will keep that in mind, thanks.

Cheers,

Tomek