I have been using latex for a couple of years, but I have never really been good enough to make it do what I want. Now I have a large report to create and I feel like now is the time to learn.
What I have at the moment is several folders each containing a chapter. The folder contains the tex file and an image folder containing the images that are going to go into that chapter. There is also a folder called root, that contains the root tex file, like follows:
What I want to do is use the \include command, or something similar, to include the latex files from the other folders. At the moment I am getting errors, and the .aux file for the chapter is being created in the root folder
. It compiles without the \include lines in it
I get the following error
[quote]I can't write on file `../chapter1/chapter1.aux'[\quote]
welcome to the board!
Perhaps your TeX configuration does not allow to include files from the parent directory, using ../ will not work then. What distribution do you use?
You could avoid that if you put the image and chapter directories below the directory of the root file.
Copyright (C) 1997-2004 Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX).
[\CODE]
I moved all the chapter folders into the same folder as the root, it probably makes more sense that way anyway! This solves my initial problem of including tex files.
I have realised that if I try to include an image in a chapter tex file with the image location relative to that file it will compile if I test just the chapter from that folder, but, obviously, the root tex file will not be able to find it. Is there a way to tell the root tex file what directory I am using for a particular tex file?
I hope this makes sense, I am just trying to set everything up so that the on computer structure has a similar logical structure to the report, and all chapters are self contained and can be tested and complied independantly.
you have to use the path relative to the root file when you include images, not to the chapter file.
Or use the TEXINPUTS environment variable, have a look at Importing graphics from “somewhere else” in the UK TeX FAQ.
Of course it is recommendable to structure your document like this. Have a look at Structuring Large Documents, this document provides useful information.
The problem is that TeX will resolve file paths relative to the main input file (or rather to the current working directory). This of course will create problems if you have nested directory structure and want to use just a part of it (like chapter1 subdirectory). And you can't change the working directory from within your source file, AFAIK.
The solution to this, that I found to be workable, is to keep everything in 1-level deep directory structure. I use the names of subdirectories as the label prefix for easy referencing. The main file also goes into subdirectory at the same level as other subdirectories. So it looks something like this:
.\main
.\chap
.\fig
and so on.
Each \input or \include has the same structure then:
Now, the advantage of such a setup for me is that I can easily experiment with the whole (or part of) project. I just create a new subdir, say 'temp', and can compile just one chapter or even a figure in there without fiddling with paths all over the place. Otherwise i would have to copy an entire directory structure into a different location and keep both of them in sync (or the hell will break loose).
I don't have any troubles working that way on MiKTeX, but when I tried BaKoMa TeX, it baulked and at \include{..\x\y} (but strangely enough accepted the same with \input!).
Another option is to use (path-like) TEXINPUTS environment variable, as Stefan suggest, and then you only need to have \input{file} in your sources. The downside of this is that you have to define this variable for each (pdf)latex run (quite easy to do with a batch/shell script wrapper) and that your text editor is unlikely to support this when scanning for included files (I find that feature very helpful in TeXnicCenter and other editors and that's why I don't use this approach).
One more trick to consider is to specify extra directories as a command line option on the first line of your master file. MiKTeX has '--include-directory' switch for that purpose:
that's a good explanation. Let me add something. First, you don't need to set TEXINPUTS on every compiler run. On a unix system I would put it into my ~/.profile file, like:
inside autoexec.bat.
If that has been done, the TEXINPUTS will be correctly set for each section automatically.
Second, I would not use \input for the chapters. In general I'm using \include, this has the big advantage that I can compile just parts of the document like chapters individually by \includeonly. That way is explained by the document I linked above.
inside autoexec.bat.
If that has been done, the TEXINPUTS will be correctly set for each section automatically.
Yes, you could do that. The downside of autoexec.bat is that any change to TEXINPUTS will force you into system reboot. That's a major inconvenience for somebody like me, who doesn't like to turn off his PC. Editing the environment through the control panel (or directly through the registry) will require restarting of the affected application (you won't find many that will respond to system broadcast about the applied changes). Not as bad as reboot but still annoying. Plus, I don't like to rely on system-wide settings (environment) for job specific stuff. I think it's a bad practice. Anyway, I suppose everyone will have their own preferences in that respect. I like to keep everything as portable and self-contained as possible so it's easy to compile on other systems if the need arises (and it keeps my options open).
As for '\include vs. \input', I don't find '\include' + '\includeonly' all that helpful (again, a matter of personal preference). I do use it, though, since it's so easy to swap it for '\input' when I need it - '\let\include=\input' does the trick .
T3. wrote:The downside of autoexec.bat is that any change to TEXINPUTS will force you into system reboot.
That's not necessary. Just execute the set command on the command line. Editing autoexec.bat is only needed if you want to keep the setting for the next reboot in the future. Though perhaps nobody reading this will use autoexec.bat the same argument is valid for newer systems too. Either I just type the export command in the shell of any unix system (or, if no bash is available, write set or setenv), or I edit my ~/.profile. That setting will be valid for the next login of my account, or after starting a shell or just executing .profile or as said typing it manually.
T3. wrote:Editing the environment through the control panel (or directly through the registry) will require restarting of the affected application (you won't find many that will respond to system broadcast about the applied changes).
As far as TeX is concerned the compiler restarts for every run and will read the environment variables.
T3. wrote:Plus, I don't like to rely on system-wide settings (environment) for job specific stuff. I think it's a bad practice. Anyway, I suppose everyone will have their own preferences in that respect.
Yes, there may be different requirements. I like the idea to configure file handling by separate settings like TEXINPUTS. If I take my tex files from my Unix OS to Windows, I probably don't need to change all my files as it might be necessary if I am using paths or sth. like \graphicspath inside. I just apply the setting one time to the other OS.
T3. wrote:As for '\include vs. \input', I don't find '\include' + '\includeonly' all that helpful (again, a matter of personal preference). I do use it, though, since it's so easy to swap it for '\input' when I need it - '\let\include=\input' does the trick .
I'm using both too. Often I just don't want the \clearpage implied by \include, then I will use \input. But again I like the idea to exclude some chapters of a very big document during development by \includeonly, because of the faster compile run, smaller output and quicker viewing. Especially now after the mainboard of my faster system is damaged and I'm using a slower one until the release of new processors in the third quarter of this year...
Changes to the environment issued from a command interpreter on Windows will be local to that particular instance of command interpreter (although they will be inherited by programs launched from it after the changes occured). I'm sure that you are aware of this detail but some Windows users might not be. Most people launch latex compilation from their text editor and not directly from the command line. In that case this editor has to be started from the process making the changes to the environment or it won't see those changes.
To tell you the truth I don't like any of the solutions discussed in this thread. Having input-like command that would resolve paths relative to the file containing the command would be the best, IMO. But there's no such command and so the 1-level deep directory layout is the second best solution I've found so far. Since the directory layout described by OP is somewhat reminiscent of the one I use, I thought that my solution might suit him the best.
Of course using TEXINPUTS is just fine as well. As long as the user understands how process environments are hanled by the system there should be no problems there. One just has to keep in mind that such sources won't compile stright away on another system, so care must be taken when sending them to others.
I think it's useful to speak about those issues and what may be good practice. I'm interested in other users opinions too. I appreciate your posts.
T3. wrote:Having input-like command that would resolve paths relative to the file containing the command would be the best, IMO.
\input and \include are able to resolve relative paths also to parent directories, it's just a security issue. On my unix system I just have to edit the file texmf.cnf to allow access to the parent directory:
the same argument is valid for newer systems too. Either I just type the export command in the shell of any unix system (or, if no bash is available, write set or setenv), or I edit my ~/.profile. That setting will be valid for the next login of my account, or after starting a shell or just executing .profile or as said typing it manually.