Would it be possible, when I launch a do-file to recover the path of the do-file as a variable?
I'm sharing a project with a co-author (via Dropbox). The structure of the folders (data, logs, etc.) is therefore the same on both sides.
But the folders are situated differented on my coauthor's filesystem and mine. It would therefore be helpful for us to write do-file that are agnostic about the path of the folders, etc.
We would like the path to our projects not to be hard-coded.
Thank you!
You can do various things in this territory, including
Passing the name of a directory to a do-file as an argument. For example,
do mydo d:/myproject/data1812
launches the file mydo.do and passes the argument of a particular directory to the do-file. Inside the do-file you can grab the argument as
local myfolder "`1'"
i.e. the thing passed is passed as local macro 1. (Any other arguments would be local macros 2, 3, etc.)
Make sure your references to locations generally and files in particular are relative within the do-file and run the do-file from the parent directory.
Use global macros within your main do-file for locations and then re-define them within a master do-file which you run first.
Notes: It's best to use forward slashes, even under Windows; Stata will translate. Also, if there are embedded spaces, bind the whole thing in double quotes.
do mydo "d:/my project/data1812"
The second seems closest to your preference for not wiring in particular locations. But if you are using files from different places you have to tell Stata somehow where they are....
creturn list. A do-file that's run without specifying where it is has to be in the current directory. Does that answer the question? –
Udela Nick's comment above gives the answer: c(pwd). This gives you a relative starting point for later commands, e.g. opening a dataset in the data folder:
use `c(pwd)'/data/yourdata, clear
Your problem might be that double-clicking a do-file does not cause Stata to set the working directory to its folder (while it does for datasets, which is inconsistent and not necessarily helpful).
There is no particular solution to that issue, except perhaps by writing your project folder path into a global macro set at startup by your profile.do file in your Stata application folder.
I teach classes of students and have them set their working directory with such a system. It works alright.
c(pwd) is the answer sought, but as Stata would understand e.g. use data/yourdata, clear too, I don't see what has been missed by not knowing that. I have only ever used c(pwd) for other purposes. I wouldn't start Stata by double-clicking on a do-file -- it presumes too much about OS settings, for a start -- but therefore agree with Fr. in identifying that as problematic. Peutch didn't specify the operating system being used, which might influence solutions. –
Udela Several years has passed but the answer is still the same: there is no direct way to determine the location of a current do-file. The discussion around this topic has been raised many times on the Statalist. You can find plenty of useful tips here (just a brief overview, more discussion on the Statalist):
In addition to those and Nick Cox and Fr. answers, I propose my humble solution to a collaborative work in Stata (that works on different machines both on Windows and Linux). It does not require additional modules and depends only on how you organize your materials in folders.
Tip 1. cd to your working directory with a hint -cap- and keep the -cd- code in the beginning of a do-file:
cap cd "W:\Bonds\" //Collaborator 1
cap cd "C:\Users\StataUser\Desktop\ProjectForBonds\" //Collaborator 2
cap cd "/media/DATA/work_materials/Dropbox/MyProjects/Bonds/" //Collaborator 3: Linux machine
cap cd "D:/work_materials/Dropbox/MyProjects/Bonds/" //Collaborator 3: PC
cap cd "E:/Projects/Dropbox/MyProjects/Bonds/" //Collaborator 3: Laptop
-cap- evades possible errors if a directory does not exist, so every user will get to his own working directory of the project. After -cd-ing to that directory you can save the path as a global variable and use it further in the code (if that is necessary):
global cdpath = "`c(pwd)'"
di "$cdpath" //show current folder
di `"{browse `"$cdpath"':Current folder}"' //optional: click to open the folder in the explorer
Hint: as Nick Cox mentioned, use "/" instead of "\". When you combine "\" with global/local variables, Stata treats this as a combination with an escape symbol (to be able to use symbols like ` and $ in strings), so using "\" may corrupt your browsing strategy. Check it via this code:
global cdpath = "`c(pwd)'"
di "$cdpath"
local i = 1
cap noi use "$cdpath\`i'\auto", clear
cap noi use "$cdpath/`i'/auto", clear
Tip 2. Keep the same folder structure by creating directories within Stata:
cap mkdir "./Temp"
cap mkdir "./Graphs"
Where "." means the current working directory. So you create "Temp" and "Graphs" folders inside the working directory. There you can store your temporary datasets, place graphs, etc.
You don't need to worry if a directory exists: -cap- alleviates this issue.
Tip 3. When saving/opening/deleting files (data, graphs, logs, etc.) explicitly tell Stata to use the relative paths:
use "./SourceData", clear
graph export "./Graphs/RollingBond.png", as(png) replace
save "./Temp/Years.dta", replace
save "./FinalBond.dta", replace
cap erase "./Temp/Years.dta"
Stata will know that you are still in your root folder and work relative to that folder. And of course you can write full paths like this:
save "$cdpath/Temp/FinalBond.dta", replace
These tips work on both Windows and Unix and only requires to write for a new user the -cap cd "..."-. Very useful when you or your collaborator work from a thumbdrive and don't have access to any other place on a computer.
© 2022 - 2024 — McMap. All rights reserved.