[tex-live] texdoc error

[Reinhard Kotucha]

Philip TAYLOR writes:

 > > Our first attempt to support network installs was to use pipes
 > > 
 > >   wget | lzmadec | tar
 > > 
 > > but it doesn't work reliably on Windows.  Some files couldn't be
 > > de-compressed properly.  We _***_wasted 3 weeks_***_ until we found
 > > out that pipes on Windows try to find out whether a file is ASCII or
 > > binary.  This can never work reliably.  When it assumes the file is
 > > ASCII it "repairs" line breaks.  The behavior is not specified
 > > anywhere AFAIK.  I searched Google ad nauseam.
 > 
 > This is an attempt to use Unix philosophies and methodologies
 > on Windows systems. When coding for Windows, the first rule is
 > to do things the Windows way.  Windows /has/ pipes, but does n
 > ot support them in any real sense.  Far better to use scratch
 > files, as all native Windows software does.

Hi Phil,
we tried to avoid scratch files for many reasons.  They are less
efficient than pipes, especially because you need CPU time for
decompressing the files but your CPU is bored when you download them.
Hence it's better to do both things at the same time.

But there are some Windows related issues: %TEMP% contains the user
name and we have to convert backslashes to forward slashes in Perl.
This will only work with ASCII, ISO-8859, or Unicode.  A Chinese
reported a problem with TL-2007 on this mailing list.  I sent him a
Perl script which converts the content of %TEMP% to hex but the result
was not very promising.  No idea how to solve such problems.

There is also c:/windows/temp which seems to be writable by mortal
users but it's quite unclear how Microsoft treats it in the future.

We also don't want to leave scratch files if the install process is
aborted for some reason.  On Unix one would provide signal
handlers.  But they don't work on Windows, except if you type ^C.

The installer uses scratch files now.  Not because we like them.  On
Windows we have no other choice.
 
 > > Whether COPY runs in binary mode or makes some assumptions by default
 > > is not specified.  Finding it out requires an enormous effort in
 > > reverse-engineering.  And an enourmous amount of time.
 > 
 > But was that work necessary ?  Would it not have been
 > better always to invoke Copy with "/A" or "/B", as above ?

No need to use copy at all.  This was only an example.  And we don't
use it.  There is a Perl function in TLUtils.pm which is completely
platform independent.  It only uses low-level system calls like
open(), close(), read(), and write().  I hoped that we can do other
things similarly but Windows is always the bottleneck.
 
 > > Sometimes it happens that I get a "permission denied" error when I say
 > > start "" "foo.pdf".  I can repair it with "chmod a+x foo.pdf" in
 > > Cygwin but Microsoft claims that the executable flag is ignored.  It
 > > is definitely not ignored by cmd.exe, but it's ignored by the Widows
 > > Exploder.  Sigh!
 > 
 > This one does intrigue me.  If there /is/ an "executable flag"
 > in NTFS, there must be some native utility for interrogating
 > and/or setting it.  "Attrib" makes no mention of it.

The Microsoft C runtime library tries to provide some Unix
functionality.  It provides functions like stat() and umask(), for
example.  However, if we are only regarding Windows, it doesn't
necesarily mean that these flags exist at all.  Microsoft just claims
that a file is regarded as an executable file if its extension is
mentioned in %PATHEXT%.  But since I can change the behavior using
Cygwin's chmod(), there must be a flag which I can turn on or off and
Microsoft doesn't tell the whole truth.

 > Just one question, Reinhard : where do <mu>Soft state that
 > "the executable flag is ignored" ?

I don't remember, but whenever I say "Microsoft claims", there are
only two sources I got information from:

 1. AFIR, you or Jerzy sometimes provided links to the "Microsoft
    knowledge base".  Google often points me to it too.

 2. The sources of the Microsoft C runtime library.  I'm not a C
    programmer but the functions are commented and at least each one
    contains a brief description about what it's supposed to do.

Manuel, you asked for a debugger.  Do you need a debugger for
executables compiled with the Microsoft C compiler?

You can download the Microsoft C compiler freely.  It's very likely
that a debugger is provided.  I don't know.  I didn't look into the
license but I supppose it's a "free-beer" one.  You are probably not
allowed to make the beer you already drunk available to other people.

Search Google for "microsoft visual c++".

The Microsoft C compiler contains the source code and header files of
the C runtime library which is used by all programs.  Hence, it's a
good reference.

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