[tex-live] texdoc error

[Zdenek Wagner]

2008/9/11 Philip TAYLOR <P.Taylor at rhul.ac.uk>:
> [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.
>
The problem with Windows pipes is that they are often ASCII, not
binary. I remember that I was not able to do tar | gzip because gzip
stopped its job at the first Ctrl-Z. Maybe it is better now, I do not
know. I ceased to use Windows a great many years ago.

>> 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
>
Execute in the security tab means that the user is allowed to execute
the file (if it is a file) or "cd" to that directory (if it is a
directory). It does not mean that the file is executable.
Executability is recognized by some other comlpex logic which I do not
understand. Since Win2000 the dos box supports filename completion by
TAB, thus instead of finding an icon of a file or an application it is
faster to open a command window, cd to an appropriate directory and
open a file. If you invoke something.exe or something.bat, the
corresponding file will be executed (if you have execute permissions).
If youo type something.doc, the file will be opened in MS Word.

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



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