# [tex-live] input

Zdenek Wagner zdenek.wagner at gmail.com
Wed Feb 27 12:26:13 CET 2008

2008/2/27, Philip Taylor (Webmaster) <P.Taylor at rhul.ac.uk>:
> I fear we are going around in circles;
>  I have tried to suggest to Steve how
>  he can achieve his aim; you have pointed
>  out that my solution will fail if his
>  texmf.cnf prohibits a reference to
>  an absolute file location; but you haven't
>  (as far as I can see) postulated a solution
>  to his real problem IF his texmf.cnf
>  forbids absolute file references.  Do
>  you believe that there is a solution in those
>  circumstances, and if so, what do you
>  believe it to be ?
>  --------
OK, I will write it more philosophically and I will end up with some
practical suggestions. It's quite a long mail...

There are four reasons why to add files somewhere and include them
into the document:

1. The document itself is too complex and splitting to several files
helps its maintanance. In such a case the correct place of the
included files is the current directory (or subdirectories), \input
uses relative paths and the included files are not used for other
documents.

2. The user needs repeatedly a set of his/her own macros. These macros
are planned to be reused in a great many documents but are not so
generic as to publish them on CTAN. Although private the file should
have a descriptive name which is distinct enough from names of other
files. Placing the file on a separate directory helps its maintanance
but searching should be based on the filename only, not on the
directory. If you have c:/somepath/macros.tex and
c:/otherpath/macros.tex, you soon forget which is which. If the file
names are (quoting my favourite book) myowninvention.tex,
cheshirecat.tex, jabberwocky.tex, you have better chance to remember
what each of them is good for. And there is small risk that a file
with the same name will exist anywhere else along the search path.
These files therefore belong to a directory which is on the search
path.

3. There is a new version of a package that is not yet present in the
installed version but the user needs its features. It should be placed
somewhere along the search path so that it is used instead of the
installed version but will not be used in the next distribution of TL
which will probably contain yet newer version of that package.

4. The user is a developer of a package and needs always the latest
version from the repository (CVS, SVN, ...). In such a case it is
better to edit texmf.cnf and add the working copy to the beginning of
the search path. Usually the package developer knows what he or she is
doing, this topic may be beyond the scope of  normal or slightly

Let's return to items 2 and 3. In my opinion proper system setup is
better then relying on absolute paths. It might be necessary to move a
file from one place to another. When you later run the file trough TeX
and it expects to find another file in an absolute path that no longer
exists, it will fail. After moving the file to another place the user
would have to modify all documents. If the file is along the TeX
search path and needs to be moved elsewhere, the user just modifies
the search path setting and all documents will work. And if you need
to switch between Windows or OS/2, where drive letters are used, and
Unix, where no drive letters exist, you run into other problems. I
know what I am writing about. I still suffer from not having proper
system setup and relying on absolute paths. Fortunatelly I always used
constructions:

\def\path{e:/some/strange/directory}
...
\input \path/file1
\input \path/file2

but still making several years old documents work is often painful.

Now let's go to the practical suggestions. Suppose that the user even
does not know where the search paths are defined (kpsewhich texmf.cnf
will find the config file). He or she just wants to take advantage of
the search paths that are already set. The search path setting may be
examined by commands as:
kpsewhich -var-value TEXINPUTS.latex
kpsewhich -show-path tex -progname latex

It is easy to understand these commands after playing some time with
them even without reading the manual of kpathsea. And looking at the
output of the commands you can see that there are several areas all of
which mimic the same directory structure of texmf-dist.

A. Imagine that you work on multiuser environment and a user wants to
make a private file not visible to other users. The best place for
such files is under $HOME/texmf. Let's suppose that Tweedledum makes his macro file /home/tweedledum/texmf/tex/newbattle/macros.tex and Tweedledee makes his private file /home/tweedledee/texmf/blackraven/macros.tex. When any of them writes \input macros, he will get his own file. If they give the file to Humpty Dumpty, it will not work because neither Tweedledum's nor Tweedledee's directories are on the Humpty Dumpty's search path (and he may have his ow different macros.tex). I am not sure whether$HOME
is used in Windows. It will definitely cause problems in OS/2 and eCS.
In such a case use B or C as described below.

B. You have a file (package) that should be used by several users and
is not included in TL and will never be there. You put such a
file/package under texmf-local/tex. Remember that texmf-dist is
searched before texmf-local and texmf-local is outside the root of TL.
If the file with the same name appears in a future version of TL, your
file will be inaccessible. That's why I say that descriptive names are
important.

C. You need version 2 of package X with new important features but
TL2007 contains version 1. If you put it to texmf-local, TeX will
still see version 1. You can edit texmf.cnf so as to change the search
order but it is not a wise solution. Imagine that time passes, you
install TL2008 containing package X version 3 but if you change the
search order too, because you need version 6 of package Y, TeX will
see version 2 of package X. OK, you delete package X from texmf-local
because you no longer need it. Then you for some reason need to
process an old file with TL2007 and it will see again version 1 of
package X. It is clear that texmf-local is not a good place for such
packages. If the new version should be visible only to one user, put
it to his or her  \$HOME. If the package should serve all users, put it
to texmf-var which is always below the TL root. Adopting this scenario
--- and without modifying texmf.cnf --- TeX in TL2007 will find
version 2 of package X under its texmf-var, TeX in TL2008 will find
version 3 of package X under its texmf-dist --- and it will work so

Moreover, if a few users work on the document that requires such a
package or file, then each of them might have it in another path. If
the document relies on absolute paths, users will have problems. If
they decide whether it is case B or C and put the files to respective
directories on their computers, the document will be processable by
all of them. It is always wise to assume that a file, which is private
today, may become useful for someone else in the future.

I hope that this long message explains the solution.

>
> Zdenek Wagner wrote:
>
>   > You can try to use the full path. If it is not allowed, you will see
>   > something like the following:
>   >
>   > (openin_any = p).
>   >
>   > ! I can't find file /opt/apache-ant-1.6.5/README'.
`