[tex-live] texdoc error

[Reinhard Kotucha]

Philip TAYLOR writes:
 > I think I worked it out ...
 > 
 > > local args_win = {}
 > > args_win [0] = "texlua"
 > > args_win [1] = '"' .. "texlua" .. '"'
 > > args_win [2] = "d:/TeX/Live/2008/texmf/scripts/texlive/texdoc.tlu"
 > > args_win [3] = "minitoc"
 > > os.spawn (args_win)
 > 
 > This also works ...

Hi,
sorry for the late answer, but there had been a lot of stuff to read.

Lua only provides os.execute(), which passes a string to a shell.  Taco
added os.exec() which is supposed to replace the current process by
another one.  It doesn't use a shell but calls the program directly.

One important difference is that if you call a program directly on
Windows, you can use forward slashes in file names because the MS-DOS
API always supported this.  But you'll get into trouble if you use
forward slashes when a command-line interpreter is involved.  The
reason is that forward slashes are treated special by the CLI.  On
UNIX, arguments separated by spaces are passed to the program and the
program is responsible for resolving its arguments, i.e. to find out
which argument is a switch, a file name, or a key-value pair.

On Windows it's not so easy because command-line options are not
delimited by spaces.  I assume that this behavior had been inherited
from VMS.  Please try:

   cd..
   dir/b/s
   cmd/?

These are all valid commands on Windows.  Sigh!

For exactly this reason we tried to avoid os.execute() and used
os.exec() instead.  What we want to achieve by our wrappers is to
replace one process by an other one in a changed environment.

However, os.exec() behaves different on UNIX and Windows because of
different implementations of the execvpe() system call.  On UNIX it
does what we expect.  It replaces the current process image by another
one and waits until it's finished.  On Windows it creates a new
process and returns immediately.  The newly created process runs in
the background.  If such a process hangs because it's waiting for user
input, all you can do is to invoke the task manager in order to kill
it. 

Thus, Taco wrote another function for us, os.spawn().  This function
avoids the CLI and is quite similar to os.exec(), but it waits until
the child process is finished, also on Windows.  And it supports
lists.  At the first glance this was the ultimate solution.

But not on Windows.  Usually, if one program invokes another one, it
passes the arguments as a list with zero-bytes as delimiters and the
other one expects exactly this.  

Obviously, on Windows the argument list you pass to another program is
converted to a string and then converted to a list again.  I don't
understand why, but maybe a CLI is involved here too.

This is what happens:

One program passes 

   foo\0this is a file name with spaces\0bar

to another program.  No problem on UNIX, it's a list containing three
elements, ("foo", "this is a file name with spaces", "bar") separated
by zero-bytes.

On Windows, however, the list is converted to a string:

  "foo this is a file name with spaces bar".

and it's converted back to a list when passed to the child process:

  ("foo\0this\0is\0a\0file\0name\0with\0spaces\0bar".)

Sigh!  You have to quote file names on Windows even if you pass them
as a zero-byte delimited list to other programs.

With all this said, the wrapper script
(bin/win32/tl-w32-wrapper.texlua) should be comprehensible.  The
function fixwin() is supposed to solve the quoting problem.

If you have any problems invoking other programs and you believe that
the wrapper script is the culprit, then please look into it:

---------------------------------------------------------
  --[[ Prepend an additional hyphen to activate this code.
  for i=0, #command do
     print (command[i])
  end
  os.exit(ret)
  --]]
---------------------------------------------------------

If you replace "--[[" by "---[[", i.e. prepending an extra hyphen, the
wrapper script doesn't invoke a particular script but it prints to
screen *how* it would invoke it.

And, if you want to know how a program is invoked, there is a very
simple trick:  Temporarily replace this program by a script which
simply prints its argument vector to screen.

Regards,
  Reinhard

-- 
----------------------------------------------------------------------------
Reinhard Kotucha			              Phone: +49-511-3373112
Marschnerstr. 25
D-30167 Hannover	                      mailto:reinhard.kotucha at web.de
----------------------------------------------------------------------------
Microsoft isn't the answer. Microsoft is the question, and the answer is NO.
----------------------------------------------------------------------------