[tex-live] texdoc error

[Philip TAYLOR]

[Disclaimer : this is not a defence of Windows,
  but rather an attempt to reduce the amount
  of wasted time in future Windows-related development]


Reinhard Kotucha wrote:

> For instance, COPY on Windows provides the switches /A for ASCII files and
> /B for binary files.  But the help message doesn't tell you what COPY
> does by default.  Don't assume it does something useful.

Perfectly true, except in the simplest cases.
The solution is always to use an explicit "/A" or "/B".

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

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

> Furthermore, not everything what Microsoft claims is true.

Probably true for all vendors : unlikely to be a sin
of commission, more probably one of omission.

> 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.  However,
the security tab reveals all, where I see that Windows actually
variously calls it "Read+Execute" and "Traverse folder / Execute
file".  Creating a test directory with no inherited permissions,
I copied a single PDF there, removed access from all but myself,
and denied myself Read+Execute access.  Result : Starts from Explorer
(double-click), error "Access is denied" when attempting to launch by

	Start "" "Payments.pdf"

Re-instate Read+Execute, and the above works.  Reinhard's
asserting is therefore born out.

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

** Phil.