Ross Moore writes:
> Should this be: getcwd() or &getcwd() or &getcwd ?
> given that there is a subroutine definition: sub getcwd {...
...
> Which are valid syntax ? Which ones should be identical ?
I really don't know; this doesn't seem to be a real problem right
now.
> ...using use Cwd ? ...using use POSIX ?
For $OS eq "solaris" , Cwd::getcwd() works, POSIX::getcwd()
doesn't.
> I don't have any machines running OS/2 so cannot test that case.
> I'll make whatever edits are needed but someone has to tell
> me precisely what is required.
I've only tested under Solaris and Linux (mostly the former).
> The default Unix version uses &getcwd() .
> Does this cause anyone any trouble ?
Not me.
> One more comment:
> Camel Book (2nd ed.) p387 says that cwd() is the safest way
> to get the current working directory.
> Should this replace getcwd() everywhere ?
This doesn't seem to work.
> I've tested a version with a -texinputs switch that allows
> the latex2html script to pass the value of $TEXINPUTS to texexpand .
> However this also requires a re-ordering of some code within texexpand .
This would be fine with me.
> The environment variable TEXINPUTS is intended for LaTeX and dvips etc.
> to find files that they need. IMHO it should *not* be used by LaTeX2HTML
> to find \input or \include files.
>
> Reason:
> It may result in files withing the TeX/LaTeX/texmf hierarchy
> being matched, and erroneously included as part of a LaTeX2HTML job.
...
> Instead those directories to be searched automatically for commonly-used
> input-files should be specified using the $TEXINPUTS variable.
...
> prior to image-generation. There should be *no other reason*
> why LaTeX2HTML uses $ENV{'TEXINPUTS'} at all.
I'm o.k. with having to modify $TEXINPUTS in my init script if I
have an opportunity to do so *after command line processing*; I want
to know the jobname to add a job-specific component. It's either that
or I have to do a little magic with environment variables or temporary
files. Such a hook should probably be called immediately before the
'foreach $FILE (@ARGV) {...}' loop in driver().
> > On a related note, l2h doesn't search for the "main" file along
> >$TEXINPUTS; is there a reason for that? I'm having to give both the
> >path *and .tex extension* to use a main document file located along
> >$TEXINPUTS.
>
> OK, I see what you mean.
> LaTeX can find the main document file not in the current directory,
> so why not LaTeX2HTML ?
I don't really care what texexpand needs; it can require the full
path or do the search. If it requires the full path, l2h needs to do
the search. The point is that the search along $TEXINPUTS should be
done "within" the system, rather than by the scripts/Makefile driving
it. For one process, I need to use kpsewhich from a shell script just
to fill in the main document filename, and that doesn't seem
appropriate.
I understand your objection about using $ENV{'TEXINPUTS'} for
locating sources, but I think it is important that if tex/latex
searches for a particular file, l2h does the same. This isn't a
technical issue, but a matter taking the "least surprises" approach.
> If you have strong views on these issues, please respond ASAP.
I hope this was quick enough! I wanted to try out a few variations
before I replied.
-Fred
--
Fred L. Drake, Jr.
[EMAIL PROTECTED]
Corporation for National Research Initiatives
1895 Preston White Drive Reston, VA 20191
