[tex-live] texdoc error

[Zdenek Wagner]

2008/9/11 David Kastrup <dak at gnu.org>:
> ...
> 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.
>
I started to use DOS at version 3.something and wrote some programs in
assembler calling DOS API functions (I even tried to write a simple
virus for didactic purposes but never distributed it). The
documentation said that some DOS API functions are modeled after CP/M,
hew API functions are modeled after UNIX. There was even a product
called "microshell" that added nice pipe features to command line in
CP/M. 25 years ago I wrote a lot of scripts for our 8-bit Robotron
with CP/M using the microshell extension.

>>> 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.
>
copy file* x:\path always assumes /B, /A and /B really matter only if
you write to stdout or read from stdin. However, copy /B file |
something is not sufficient, if "something" reads the pipe as ASCII,
you are lost, it will stop at the first Ctrl-Z.

I have also tried to concatenate files by
copy /B file1+file2 file3
Unfortunatelly concatenation works with ASCII files only and /B is
ignored. I do not know whether M$ fixed this bug, I have not tried it
for several years.

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



-- 
Zdeněk Wagner
http://hroch486.icpf.cas.cz/wagner/
http://icebearsoft.euweb.cz