# Latex Macros: Local Variables and Path Names

I initially have a group of TeX codes that looks like so:

paper.tex
assignment.tex


Where paper.tex is the main TeX and takes in the assignment.tex file and adds it in there.

The assignment.tex is the one I am concerned with and it has a snippet of code that I want to change. It looks like so:

\inputdir{sigsbee}
\multiplot{2}{img1,img2,img3,img4} %where img1-4 are within the directory sigsbee
{width=.45\textwidth}{caption1;caption2;caption3;caption4}

\inputdir{sigsbee2}
\multiplot{2}{img1,img2,img3,img4} %where img1-4 are within the directory sigsbee2
{width=.45\textwidth}{caption1;caption2;caption3;caption4}


I would like to make a third multiplot that takes images from both sigsbee and sigsbee2 and plots the images.

I was hoping to use something that would define variables based on path names that I could append to include miscellaneous directories. Something like:

\def\path[#1]{'/path/to/file/#1'}
....
\multiplot{2}{\path{sigsbee}{img1,img2,img3,img4}}


But I am unsure on the notation or approach that would be best suited for this operation.

• If those are regular png's (or any other image format inset by \includegraphics) just do: \graphicspath{{sigsbee}{sigsbee2}} and extend with as many paths as necessary. Note the extra braces and no comma separator. Then you should not need \inputdir. – zeroth Mar 3 '15 at 18:53
• @zeroth Just out of curiosity if I specify the graphics path and have images named the same thing will it still be okay? Something like: '\includegraphics[]{\graphicspath{{sigsbee}}img1}' will register the image in sigsbee as opposed to any other paths? Or should \graphicspath be defined in the preamble? – msleevi Mar 3 '15 at 19:01
• I can actually not remember, try and see if it works (but do not put \graphicspath inside the command), or read in the graphics manual. I have always put it in my preample, if it is just appending to an internal non-global macro, it should work, otherwise you need to do something else. – zeroth Mar 3 '15 at 19:16
• @zeroth I read up on it and that makes sense. I definitely wouldn't put it in the command. But the problem with that would be that my images are the exact same title in each directory. So I would need some way to differentiate each file from the others. It would be nice if I could do something like '{sigsbee}+'definingfolder/file' but I don't know how to overload operators in TeX. – msleevi Mar 3 '15 at 19:23
• It is a bit unclear what multiplot actually does. If it is one of your macros you can edit it to split its arguments to have something executed in the middle. I think it this case you are better of by setting path to {} and then prepend the actual path to each image. – zeroth Mar 3 '15 at 19:37

Given the amount of time it has been since someone has contributed I am going to post my personal solution to this problem. And it is not actually a solution. Initially I prosed this question because I did not have access to the template file where part of the macros were defined from. The macros in question were as follows:

\newcommand{\@path}{.}
\providecommand{\figdir}{Fig}
\providecommand{\fig@file}[1]{\@path/|figdir/#1}


Now unfortunately this question was doomed from the point I asked, I did not really when I posed this question that there is a great deal of background information transformed that is highly dependent on the naming convention of the paths for the working directory. This is a Madagascar convention which is the software from where this question arose.

There is no possible way to answer this because if you change the \inputdir{} the next directory that it searches for is the Fig directory. Which is unfortunate. The simplest solution to this problem is to alter the constructing python script to make all the potential figures in one directory.

The more complicated solution would be to alter all the dependencies within the TeX template and the macros in order to make it more suitable for using multiple directories within the \multiplot{}{}{} environment.

Unfortunately, I don't see any foreseeable answers to this problem as the problem is ill-defined and frankly bordering on useless because the whole template is based on this naming convention for the paths. I would like to see a better solution arise, but I am not hopeful.