# Relative paths for \input and building from different directories

## The minimal example

If I have a directory containing my main LaTeX source file and it uses \input to incorporate some data in another file, I can use a relative pathname. E.g., with these files:

### ~/tmp/relative-paths-mwe/mwe.tex

\documentclass{article}
\begin{document}
\input{./src/ex.tex}
\end{document}


### ~/tmp/relative-paths-mwe/src/ex.tex

some input


Now, from the command line, if I'm in ~/tmp/relative-paths-mwe, I can build as expected:

~/tmp/relative-paths-mwe$pdflatex mwe.tex This is pdfTeX, Version 3.1415926-2.5-1.40.14 (TeX Live 2013) ... Output written on mwe.pdf (1 page, 12192 bytes). Transcript written on mwe.log.  However, if I'm in the parent directory, ~/tmp/, I can't build because the relative paths (as I understand it, and based on the symptoms) are resolved with respect to the current working directory rather than the file where the \input appears: ~/tmp$ pdflatex relative-paths-mwe/mwe.tex
...! LaTeX Error: File ./src/ex.tex' not found.

Type X to quit or <RETURN> to proceed,
or enter new name. (Default extension: tex)

Enter file name:


Is there a way to specify the paths in such a way that I can refer to other content using relative paths, but still be able to call pdflatex from arbitrary directories?

## The non-minimal example

I think that the above is a complete minimal working example for which if I get an answer, I can solve my actual problem. In case there's a difference that someone can predict in advance, or anyone is wondering why I'm trying to do something unusual, a bit of explanation is in order. I've got a source repository for a project, and it has a subdirectory for a LaTeX document, and a subdirectory for an Apache Maven project. The document had been using the listings environment to include source code from the Maven project using relative paths along the lines of

../mavenproject/src/more-path/code.extension


There's a LaTeX Maven Mojo that's supposed to be able to compile LaTeX documents, so I decided to try moving the document directory to mavenproject/src/latex/mydoc. Now, I can build the document manually from mavenproject/src/latex/mydoc if I change the relative paths to

../../more-path/code.extension


but I can't build with those paths using the LaTeX Mojo, because it's run from the mavenproject directory, which is several directories up from the document root. I can obviously adjust to handle that, but then I can't build from mydoc anymore. I'm hoping that there's a way to specify the pathnames relative to the including document, or to specify the a document root, and write paths relative to that. I hope that a solution to the minimal example above will transfer over to my actual situation.

• The typical advice for path is to either put all your files into one directory or use TEXINPUTS. Jan 14, 2014 at 8:59
• @MartinSchröder all of my latex source is in the same directory, actually. I'm documenting some program code that needs to be in another tree, and that's how this is actually arising. It's not uncommon, from what I've seen, though, to break larger documents into multiple files that reside in various subjects res, and that are referenced by relative path names. Jan 14, 2014 at 11:40
• @MartinSchröder Is it expected, then that relative pathnames in files are resolved against the current working directory of the pdflatex (latex, etc.) directory, rather than the directory containing the file? That seems to break the concept of a relative pathname. Shouldn't we expect \include{./foo.tex} in a file bar.tex to look for foo.tex in the same directory as bar.tex? Jan 26, 2014 at 1:00
• @JoshuaTaylor It's not the current file that processes itself, but the overall pdflatex process. If you do a complex C compilation, you can move from a directory to another and use relative paths, but only when compiling one of the .c files. Then a linking phase takes place, but there's no analogy with linking in TeX: everything is obtained in a unique run. One could modify \input (not \include, I'm afraid) to use a path relative to the file it's called from. Jan 26, 2014 at 12:05
• I am lazy, so I put my include file in $HOME (only have one include file), since that is searched by default by Latex. Otherwise, as others said, use$TEXINPUTS Apr 5, 2014 at 0:11

Rather than

\input{./src/ex.tex}


It'd usually better to do

\input{ex.tex}


then use (from anywhere)

TEXINPUTS=$HOME/tmp/relative-paths-mwe//:$TEXINPUTS: pdflatex mwe


It isn't really that relative paths are resolved against the current working directory but rather they are resolved against the directories in TEXINPUTS (whether specified as an environment variable or a kpathsea configuration in texmf.cnf file. By ending the path with // you allow subdirectories to be searched so the ex.tex will be found in the src subdirectory, as well as the mwe.tex from the commandline. the trailing : in TEXINPUTS ensures that the standard places are also searched for the usual classes and packages.

• How do you include TEXINPUTS command line to MikTeX ? Jul 31, 2014 at 4:39
• @Mappi never used miktex sorry:-) Jul 31, 2014 at 8:44
• It is a shame that TeX does not allow relative paths. It is totally dumb that one "file" that includes another "LOCAL FILE" has to be aware of its global location. Or, that the user has to be aware of what TEXINPUTS s/he should use to work around such a silly limitation. I will never understand why developers insist on such a ... decision. Jun 22 at 11:50
• @AndréCaldas TeX was designed before hierarchical file systems..... But when is it ever an issue? I have used tex for over 30 years and this has never caused an issue, tex does of course understand relative paths you can \input{aa/bb}` to input bb.tex from the aa subdirectory of the working directory (or in fact the aa subdirectory of any directory in the input path, what else do you need? Why do you say it has to be aware of global location? Millions of tex files get moved from place to place and re-run with no changes needed. Jun 22 at 15:51
• @DavidCarlisle: Hierarchical file systems is more like the internal representation of the file system. The way one looks at the file system does not have to be the same way it was implemented. For example, in windows people use \ instead of / and, nonetheless, "/" works fine if you use TeX in windows. Independent if its internal organization, a file system gives names to files. You don't need an hierarchical file system to, inside a aa/x.tex, y.tex could easily mean aa/x.tex. I do understand why it WAS the way it was. I just don't understand why IT IS, now. :-) Jun 23 at 16:20