[l2h] Re: [BUG][PATCH] TEXINPUTS handling.

Ross Moore ross@ics.mq.edu.au
Sun, 29 Sep 2002 15:24:31 +1000 (EST)


> [please CC me. I am not subscribed and don't know where to read it online]
> 
> 	Dear latex2html developers,
> 
> As I know _nothing_ about Perl, nor about latex2html I am a bit reluctant to 
> make strong statements. However:
> 
> Is it me, or the handling of the environment variable TEXINPUTS completely 
> broken in latex2html? If this is true, this problem seem to exist for more 
> than a couple of years... 

LaTeX2HTML is *not* a TeX engine; it interprets user's high-level LaTeX
documents. It avoids .sty and .cls files, since these typically contain
low-level TeX coding for detailed layout of items on a printed page.
Mostly these have *nothing whatsoever* to do with designing an HTML
file for presenting the contents of the high-level source.

So  $ENV{'TEXINPUTS'}  and $TEXINPUTS  are indeed different variables,
They serve similar purposes, in one sense, but are quite different
in another sense, due to the differences between the requirements
for .dvi and HTML output.


> The argument which represents the TEXINPUTS variable which is passed to 
> texexpand is unrelated to what I have in my environment, just before invoking 
> latex2html (I added some print statements to check this).

That is because almost nothing that can be found on the typical TEXINPUTS
paths has any relevance to the job that LaTeX2HTML is to perform.
Indeed, if TEXINPUTS were to be passed, then it is quite possible to
pick up input files that have nothing whatsoever to do with the HTML
translation.


If you need to include LaTeX source from other directories,
then you should use $TEXINPUTS as *a Perl variable* from within
an initialisation file, to specify these directories.

It is perfectly normal, with LaTeX2HTML jobs, to set Perl variables
within an initialisation file that will be specific to the
particular job, or to all jobs run from a particular directory.
Usually this file is called  .latex2html-init .

If you wish to describe this as TEXINPUTS being completely broken,
then, yes it is; but to do it differently would be much, much worse. 
 

> It seems that the internal variable TEXINPUTS has been confused with the 
> environment variable $ENV{'TEXINPUTS'} in the final assignment in the 
> subroutine absolutize_path. What happens at present is that the environment 
> variable with this name is modified, while the _internal_ variable is later 
> passed to texexpand (using its -texinputs option).

Yes; that is correct.
The environment variable can be relevant when LaTeX2HTML asks LaTeX
to create images; but before this point in the translation procedure,
it has little relevance at all.


> The one-liner patch below (against the latex2html-2002-2 drop, but probably it 
> applies to older versions as well) fixes the problem by rather assigning the 
> absolutized path list to the $TEXINPUTS variable.

Why do you feel that you need this ?
It is a dangerous thing to do, since you can confuse files containing
TeX-only coding with the real LaTeX source.
I've had instances where a file named  example.tex (say) was pulled-in from
somewhere in the TeX-tree, because the TEXINPUTS environment variable
was being searched irrelevantly; since then, the coding in LaTeX2HTML
has been as it is now.


A relevant point here is that many installations set TEXINPUTS as an
environment variable, for access to system-wide TeX resources.
It helps TeX find .sty and other files, which LaTeX2HTML does not want
to find at all.
Most users have no idea of the value of 'TEXINPUTS' used this way.

While it may be OK to mix user-defined paths and system-wide paths
for LaTeX jobs handled by TeX, it is quite wrong to do this with
LaTeX2HTML. It can result in irrelevant files being included
as part of a job. When this happens, the typical user would have
no idea why this has occurred, and would not be able to fix it.

 
> By the way: Latex2Html rocks, thanks! Our (quite complex) generated latexfiles 
> are converted almost perfectly. If only somebody could implement the 
> listings.sty ;-) 

I'm glad to hear this.

If the purpose of  listings.sty  is to provide verbatim listings of 
computing code, then try using  verbatim.sty  and/or  verbatimfiles.sty .

What else does  listings do ?
 line-numbers ?  ---- that's quite hard
 expand-tabs ?  -- that's easy
 syntax-highlighting ? --- you cannot use HTML's <PRE>....</PRE> tags
                           so this would be very hard.


Hope this helps,

	Ross Moore


> 	Kind Regards,
> 
> 	Jan van Dijk
 
> eldhcp16:/usr/local/src/latex2html-2002-2 # diff -u latex2html.orig latex2html
> 
> --- latex2html.orig     Sat Sep 28 19:08:13 2002
> +++ latex2html  Sat Sep 28 19:09:01 2002
> @@ -1256,7 +1256,7 @@
>      };
>      if ($ROOTED) {$TEXINPUTS .= "$envkey$FIXEDDIR"}
>      $TEXINPUTS = &absolutize_path($TEXINPUTS);
> -    $ENV{'TEXINPUTS'} = join($envkey,".",@_,$TEXINPUTS,$ENV{'TEXINPUTS'});
> +    $TEXINPUTS = join($envkey,".",@_,$TEXINPUTS,$ENV{'TEXINPUTS'});
>  }
> 
>  # provided by Fred Drake