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

[Jan van Dijk]

	Hi Ross,

Thanks a lot for your swift reply. Setting $TEXINPUTS in a local 
.latex2html-init the did the trick, indeed.

Might this issue be faq material? Many users (like me) will probably see 
latex2html as `just another .tex converter'. That is: as one of the programs 
from the list:

	latex:		tex->dvi
	pdflatex:	tex->pdf
	detex:	tex->ascii
	latex2html: tex->html

And the ignorant expects the environment variables (like TEXINPUTS) which 
control these apps to behave more or less similarly. I did. Unfortunately I 
know too little about the details to phrase that faq correctly myself. In the 
existing faq-list there is a lot about TEXINPUTS, but all seamingly unrelated 
to this issue.

About listings.sty: indeed, it does line numbers, tab expansion and syntax 
highlighting. But also a list-of-listings, labeling and referencing of line 
numbers, line-breaking, and much more. Thanks for considering it.

Thanks again for your reply. It surely helped a lot.

	Regards, Jan van Dijk

On Sunday 29 September 2002 07:24, Ross Moore wrote:
> > [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.
>