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

[Reinhard Kotucha]

On 2011-05-15 at 11:45:01 +0200, Philipp Stephani wrote:

 > Am 15.05.2011 um 00:36 schrieb Reinhard Kotucha:
 > 
 > > On 2011-05-14 at 02:43:31 +0200, Philipp Stephani wrote:
 > > 
 > >> [...] 
 > >> 
 > >> The Microsoft Visual C runtime is the current standard C runtime
 > >> and not at all old or outdated.
 > > 
 > > Hi Philipp,
 > > thank you very much for the comprehensive response.
 > > 
 > > I was confused by different behavior of cmd.exe and the Exploder,
 > 
 > What exactly is the different behavior? AFAIK cmd doesn't accept /
 > as a path delimiter (due to historical reasons, of course...), but
 > that's about it. Missing Unicode support is generally caused by the
 > non-Unicode font that is used by default.

There were differences regarding file permissions.  In cmd.exe I was
sometimes unable to [re]move files.  I got a "permission denied" error
though I could [re]move the files in the Exploder.  I don't know what
caused the file permission problem, but I vaguely remember that it
sometimes could be solved by setting the executable flag under Cygwin,
though I don't understand why.

Another thing are UNC paths.  Try:

   start "" \\server\path\to\file.pdf

And there is also the encoding mess.  We had TortoiseSVN, which was
running in the Exploder and thus used CP1252.  When I committed files
on the command line (cmd), CP850 was used and non-ASCII characters in
log messages were not displayed properly in the GUI.  I tried "chcp
1252" in the CLI but cmd.exe obviously didn't support it.

There is also another issue, besides that reported by Mojca and Ulrike,
regarding the display of filenames.  Put a Type 1 font into
c:\windows\fonts.  The CLI (dir) lists both, the PFB and the PFM file,
while the Exploder only shows the PFM file.

That was on XP SP2, I've never used Vista or W7, but I don't expect
much progress anyway.

Regarding forward slashes, I think that cmd.exe can deal with them
unless you pass a file name containing them as path delimiters to a
program which interprets them as prefixes for optional arguments.

It's the Exploder which doesn't accept them as path delimiters.  If
you enter a file name with forward slashes, the Exploder prepends
"http://" to the path, which is probably not what you expect. :) 

Furthermore, the gap between the CLI and the GUI seems to increase.
On a German XP there was a directory c:\Programme.  This directory was
displayed by the Exploder too.  Under Vista, programs are installed
under "c:\Program Files", but the Exploder shows the non-existent
directory "Programme" instead.

I'm a bit wondering that you say that the only difference between the
CLI and the GUI is how they handle forward slashes and file names
beginning with a dot.  I have the impression that Windows (please note
the plural) are at least two distinct operating systems, NTVDM
provides a third one, and I've heard that even some XP programs are
virtualized too under W7...

However, I think that you, as a C programmer, don't have to worry so
much about the limitations of cmd.exe.  But if you are using Perl or
Emacs, you can't avoid shell escapes.  I encountered the problem with
file permissions in Emacs, which calls "cmd /c delete ..." in order to
delete a file.  When we wrote the installer, we encountered severe
problems with pipes.  They are implemented in cmd.exe and don't
support binary files reliably.  As a C programmer you would certainly
avoid the shell and use popen() directly, which can be forced to
binary mode.  The pipes implemented in cmd.exe are *guessing* whether
a file is a text or binary file and try to "repair" line endings
occasionally.

You recently said:

 > If I read perldoc perlfunc correctly, something like
 > open(HANDLE, "-|", "command", "arg1", "arg2", ...)
 > should do the job, provided that maps to the correct CreateProcessW
 > invocation (with conversion to UTF-16 and proper quoting) on Windows
 > and to a fork/exec or spawn_process invocation on Linux and OS X
 > without going through any shell or standard C function.

Well, since we painfully had to learn that even if you pass arguments
as a list to execve(), you still have to quote arguments because
Windows converts the argument list to a string and then back to a list
internally, before passing the arguments to its child process, I doubt
that even low-level functions avoid the shell.

If you are aware of specifications from Microsoft which explain how
Windows is messing up the execve() argument list before passing it to
the new process, please let us know.

Look at

  texmf/scripts/texlive/rungs.tlu 

in order to see how we solve the problem ATM.  It would be nice to
have the annoying function fixwin() integrated in texlua, similarly as
it's integrated in Perl.  However, Taco won't do that without a clear
specification from Microsoft.  Understandably.  But we didn't find any
specifications so far.

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