[tex-live] [luatex] [lltx] Location of recorder file

Reinhard Kotucha reinhard.kotucha at web.de
Thu May 19 01:19:32 CEST 2011


On 2011-05-17 at 22:49:39 +0200, Philipp Stephani wrote:

 > 
 > Am 17.05.2011 um 22:23 schrieb Reinhard Kotucha:
 > 
 > > The gap between stock Lua and LuaTeX is already quite large.
 > > What I miss in stock Lua is TeX, for example. :)
 > > 
 > > Well, I don't think that the gap has to be kept small in the
 > > first place.  Lua is designed to be embedded in programs on a
 > > particular platform and is not aware of the operating system at
 > > all.  It just inherits behavior from the operating system it runs
 > > on, for instance line endings.  I'd like to use texlua as a
 > > general, platform independent scripting language without the need
 > > of conditional code for different platforms in the scripts.  As a
 > > first step into this direction, Taco made io.read('*lines') line
 > > ending neutral.  There are not many differences between Lua and
 > > LuaTeX, mostly extensions, which are described in the manual.
 > > 
 > > Lua provides os.execute() as the only function for calling
 > > external programs.  Taco added os.exec(), which was supposed to
 > > replace the current process image by another one.  Since this
 > > doesn't work as expected on Windows, he added os.spawn().  All
 > > these functions expected a string as an argument, which means
 > > that file names with spaces have to be quoted in each script,
 > > which is quite annoying.  Also, string concatenation is quite
 > > ugly.  With table support we can simply pass arg{} to the new
 > > process.
 > 
 > Additions don't cause problems, it's more the changes I'm a bit
 > worried about. I think that changed functionality should generally
 > be reflected in an interface addition. What happens if I run a
 > script that expects stock Lua behavior through TeXLua?

You don't have to worry about line endings. :)
I'm not aware of incomatible changes, except that lexlua doesn't
support locales, in sake of portability.
 
 > > Therefore I asked Taco to add support for Lua tables to
 > > the new functions.  They now accept either a string or a table.
 > > 
 > > If you pass arguments as a table, you don't have to quote, except on
 > > Windows.  I looked at the description of CreateProcess() and it seems
 > > that it accepts a string only.  However, I suppose that
 > > 
 > >  http://msdn.microsoft.com/en-us/library/20y988d2.aspx
 > > 
 > > is the specification Taco was missing.
 > 
 > Yes, that is just the conversion from the argument vector to the
 > command-line string that CreateProcessW expects.  But then you
 > still have to write wrapper code for CreateProcessW, convert the
 > UTF-8 arguments to UTF-16, etc. Not hard to do, but adds even more
 > platform-specific code to LuaTeX.
 > > 
 > >> The best thing would be to write an extension module that wraps
 > >> CreateProcessW directly.  If it's only about calculating the
 > >> command line from an argument vector (i.e. the list2cmdline)
 > >> function, then that can be done in pure Lua.
 > > 
 > > Sure, this is quite similar to what the fixwin() function does,
 > > though the latter doesn't create a string, but it would be much
 > > nicer if we can avoid it completely.
 > 
 > The problem remains that unless you wrap CreateProcessW or at least
 > wspawn* directly, you never get Unicode support on
 > Windows. Therefore you have to add platform-specific code
 > anyway. It's a bit less if you call spawn/wspawn, but it's still
 > there.  If you really want to make Lua truly platform-independent,
 > you have to add those Unicode wrapper functions for Windows. No
 > Unicode support on a Unicode operating system is almost
 > unacceptable.

In principle, yes.  But I'm sceptical in respect of Unicode file
names.  Sounds non-trivial.  Does io.open() in stock Lua convert UTF-8
encoded file names to UTF-16 on Windows?

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.
----------------------------------------------------------------------------


More information about the tex-live mailing list