[tex-live] texdoc error

[David Kastrup]

Philip TAYLOR <P.Taylor at Rhul.Ac.Uk> writes:

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

I don't consider minimally useful documentation or consistent behavior
to be a "Unix methodology".

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

Using scratch files does not change the binary/ascii problem.  And pipes
certainly _are_ part of the Windows way.  DOS introduced the open/close
system calls pretty much from the start (2.0 or something?) as an
alternative to the previous CP/M FCB file handling.  By now the
DOS-based FCB file handling is gone.  For better or worse, Windows file
handling is using Unix-style system calls and interfaces.  So there is
no reason not to get them right.

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

If you are calling it by hand, you know what kind of file you are
handling.  If you are working on wildcards or parameters/variables, you
may not necessarily have that information available.

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

In the case of Microsoft, you have to fork over a few thousand quid in
order to be allowed to even report a problem (let alone have it fixed).
That tends to leave things in a bad state rather than having them
reported and fixed.

-- 
David Kastrup