[tex-live] Disappearing text

[jfbu]

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

this is a guess

best regards

Jean-Francois