[tex-live] Disappearing text

[Zdenek Wagner]

2013/12/21 jfbu <jfbu at free.fr>:
>
> Le 21 déc. 2013 à 15:59, Artur Zaroda <zaroda at mimuw.edu.pl> a écrit :
>
>>
>> This happens on Ubuntu 12.04 with TexLive 2009 and on Windows with
>> fresh installation of TexLive 2013.
>>
>> For a do-it-yourself minimal working example, in the following:
>>
>> \documentclass{article}
>> \usepackage{comment}
>> \includecomment{a}
>> \includecomment{b}
>> \begin{document}
>> \begin{a}
>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>> \begin{b}
>> \end{b}
>> 0123456789 0123456789 0123456789 0123456789 0123456789
>> \end{a}
>> \end{document}
>>
>> repeat the line with 62 '%' characters exactly 64 times.
>>
>> The resulting document is shortened to:
>>
>> 0123456789 0123456789 0123456789 0123456789 01
>>
>> Artur Zaroda
>
> I confirm this with TL2013  on Mac OS X.
>
> This is perhaps more a comment.sty issue than a TeX Live, although
> the detailed explanation (which I am curious to learn) might depend on
> TeX Live (or rather on the details of TeX’s dealings with input/output of files).
>
> When the comment package finds a comment environment
> it writes its contents to a file called comment.cut, and at the end of the environment
> decides to include back the file or not (*)
>
> (*) I don’t know why this decision is done only after the environment
> contents have been output verbatim to the comment.cut file as it could
> have been identified from comment.sty that ‘a’ was not to be commented out
> after all
>
>  So here we have ‘a’ and then an \input
> is done which reads 64 lines of 62 percent signs, then \begin{b} and this starts
> again the process as environment ‘b’ was also declared in the preamble to require
> comment.sty interference
>
> When a file is opened up for write operations its contents
> are instantly erased, so comment.cut which already served for ‘a’ is erased
> for ‘b’ to write its contents (here nothing) and then again input. Somehow
> we are left with a partial version of the first input: precisely
> 4096 characters (including the EOL’s).
>
> Possibly, when TeX encounters \input file.tex it
> proceeds by blocks of 4096 (as no smaller power of 2 seems to give the same effect
> in my brief testing just now
> and this might be file system dependent)
> and loads from disk the next 4096 characters only when needed. Thus it loaded
> everything up to and including 01, then the file was erased by the process described
> above
>
4096 bytes is usual buffer size. Maybe the file is not properly closed
before subsequent input. I just guess, I have not looked at the source
code of the package.

> this is a guess
>
> best regards
>
> Jean-Francois



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