Relative paths in .do files?

[Shannon Campbell]

When one is referring to specific files in a .do file--i.e., use "C:\Desktop\Project A\123.dta", clear--is there a way to set it to be relative to wherever the .do file is stored, rather than a set path?

It's a major pain when I reorganize my files (or someone else does!), and all my paths in saved .do files are now invalid and I have to fix them. Say, adding my "Project A", "Project B", and "Project C" folders into one "2018" folder--now I need to go change every instance of "C:\Desktop\Project A\123.dta" to "C:\Desktop\2018\Project A\123.dta"

[William Lisowski]

In general, no, Stata does not keep track of where the currently executing do-file executing from. My workstyle is such that my do-files files copied to new directories a lot - either as a crude version control, or because they're forming the basis of a new project. So I do not hard code paths into the do-files. Instead, I create local macros at the top of each do-file as needed. So the bad news is, it's not automatic, but the good news is, just one change per do-file.

Stata does know what your current working directory is, however, so if you make a practice of changing your working directory to the directory containing your do-files, then all references can be relative to that directory, rather than a full path.

[Chris Larkin]

Building on William's answer, you can also indicate in Stata how far you'd like to go back along a path. This could save you some (but likely not all) bother as and when files/folders move around on your machine. You can do this by typing two periods and a back slash when you specify the path. E.g.

*New do-file
local dir "C:\Desktop\2018\Project A"
cd `dir'

*Bring in data
use 123.dta, clear

*Data's now been moved to Project B
use "..\Proiect B\123.dta", clear

[ghoetker]

The practice I've developed with co-authors is to not include a "base" directory in my do-files. It is then the user's responsibility to change the working directory to the appropriate directory before running the do-file. Relative files work very well from this, so long as you maintain a constant directory structure for each project. For example, for the project "SuperProject", my do files will always be in /[somepath]/SuperProject/Models. They can reference raw data files (which are stored in /[somepath]/SuperProject/Data) as "../Data/file1.dta". Graphs can be saved as "../Graphs/Graph1.gph", etc. Now I can move the "SuperProject" folder anywhere I want and everything works fine. Similarly, it's not a problem that my computer "sees" the SuperProject folder at /Users/Glenn/Dropbox/SuperProject, but my co-author's computer sees it at C:\Users\Eddy\Dropbox\Super Project.

The fastcd package, available on SSC, obviates the small inconvenience of having to change to the appropriate working directory to start with.

[William Lisowski]

Chris's helpful advice reminds me that, since I recommended local macros and you are on a Windows system, I should post the following warning from my FQA (Frequent Question Answers) file.

The backslash character

\

has meaning to Stata: it will prevent the interpretation of any following character that has a special meaning to Stata, in particular

`

will not be interpreted as indicating a reference to a macro.

But all is not lost: Stata will allow you to use the forward slash character in path names on any operating system, and on Windows will take care of doing what must be done to appease Windows.

. local prefix batch42

. display "Q:\HOME\`prefix'_filename"
Q:\HOME`prefix'_filename

. display "Q:/HOME/`prefix'_filename"
Q:/HOME/batch42_filename

[Robert Picard]

Also see project (from SSC). It automatically changes Stata's current directory to the one that contains the currently running do-file. The typical set up is to have a master do-file which runs nested do-files, each of which can also run nested do-files, and so on. The directory that contains the master do-file is the master directory. Within do-files, you can refer to files simply by their file name if they are in the same directory as the calling do-file or you can use a file path that is relative to the master directory.

The name of the master do-file defines the name of the project. For example, if the master do-file is called "xyz.do", then you build the project using

project xyz, build

and project will then run the master do-file. With project, you never run a do-file in isolation, you always rebuild the whole project. This may appear inefficient, especially as a project increases in size and complexity but project is smart and can track changes in do-files. If a do-file has not changed since the last build and none of the files it uses or creates have changed either, project will not run the do-file for the current build. Thus you can have a mature project with hundreds (or thousands) of do-files, each using and creating even more files (of any kind) and project will only re-run do-files that have changed since the last build AND do-files that must be run again because the files they use have changed as part of the ongoing build.

When work is finished on a project, you have a self contained project with all code, data, figures, and tables within a master directory (and a bunch of subdirectories, each of which can contain subdirectories, and so on) that can be zipped and submitted in support of a manuscript to a journal. Anyone can download the archive and the code will run on any platform (Mac, PC, etc) without having to make a single change to adjust for file paths.