Does Stata have something (more or less) equivalent to FILE HANDLE in SPSS?

[Bruce Weaver]

In SPSS, one can use FILE HANDLE commands at the top of a syntax file to define paths to folders one wishes to read from or write to. This is useful if the syntax might be used on another computer with a different folder structure: One can modify the FILE HANDLE commands at the top of the file rather than having to find and modify every read & write operation throughout the syntax file.

EDIT: I forgot to include a link to the help for FILE HANDLE. Here it is: http://www.ibm.com/support/knowledge..._overview.html

I was trying to figure out how to achieve that same functionality in Stata. Google searches took me to some old Statalist discussions that suggested using local macros to define paths to folders, like this:

// Use local macros to define data and log folders:
local datafolder  "C:/bw/Stata/IVRMUS/data"
local logfolder  "C:/bw/LU/PSYC/5151/2016/Stata log files"

* Open the log file.
* Notice the use of the logfolder macro on the next line:
log using "`logfolder'/IVRMUS-04", replace text name(log4)

* Open the data file.
* Notice the use of the datafolder macro on the next line:
use "`datafolder'/gss_ivrm", clear

* And so on, with the datafolder macro used throughout.

This works perfectly when I run the entire DO-file in one go. However, if I run it piecemeal (which one often does while developing the code), the macro definitions appear to be lost. For example, I get an error message like this when attempting to run one of the use commands part way down the file:

. use "`datafolder'/gss_ivrm", clear
file /gss_ivrm.dta not found
r(601);

So back to my question: Does Stata have anything like the FILE HANDLE command in SPSS? If not, what is the best way to achieve that same functionality? And can it be done in a way that works even when one runs the DO-file in piecemeal fashion?

Version & OS info: Stata 13.1; Windoze 7 Professional (with SPs)

Thanks,
Bruce

p.s. - Note that I used forward slashes (/) in all of my folder references, so this has nothing to do with the backslash problems with macros noted in one of Nick's SJ articles. It couldn't be that anyway, given that the DO-file works perfectly when I run it all in one go.

[Richard Williams]

I suppose you could use global macros, perhaps resetting them when all is done.

[Bruce Weaver]

Thanks Richard. I had tried changing local to global on the lines that defined the macros, but had not yet done enough reading, and did not realize that global macros are called via the $ prefix, not the `single quotes'. The following seems to work just fine.

// Use global macros to define data and log folders:
global datafolder "C:/bw/Stata/IVRMUS/data"
global logfolder "C:/bw/LU/PSYC/5151/2016/Stata log files"

* Open the log file.
* Notice the use of the logfolder macro on the next line:
log using "$logfolder/IVRMUS-04", replace text name(log4)

* Open the data file.
* Notice the use of the datafolder macro on the next line:
use "$datafolder/gss_ivrm", clear

I'm not finding anything when I search for how to "reset" a global macro. Do you mean to simply redefine it as a null string? Or is there another way?

Cheers,
Bruce

[William Lisowski]

Here's a demonstration.

. macro list _all
S_level:        95
F1:             help advice;
F2:             describe;
F7:             save
F8:             use
S_ADO:          BASE;SITE;.;PERSONAL;PLUS;OLDPLACE
S_StataSE:      SE
S_FLAVOR:       Intercooled
S_OS:           MacOSX
S_OSDTL:        10.11.6
S_MACH:         Macintosh (Intel 64-bit)

. local foo x

. macro list _all
S_level:        95
F1:             help advice;
F2:             describe;
F7:             save
F8:             use
S_ADO:          BASE;SITE;.;PERSONAL;PLUS;OLDPLACE
S_StataSE:      SE
S_FLAVOR:       Intercooled
S_OS:           MacOSX
S_OSDTL:        10.11.6
S_MACH:         Macintosh (Intel 64-bit)
_foo:           x

. local foo

. macro list _all
S_level:        95
F1:             help advice;
F2:             describe;
F7:             save
F8:             use
S_ADO:          BASE;SITE;.;PERSONAL;PLUS;OLDPLACE
S_StataSE:      SE
S_FLAVOR:       Intercooled
S_OS:           MacOSX
S_OSDTL:        10.11.6
S_MACH:         Macintosh (Intel 64-bit)

.

[Bruce Weaver]

Got it! Thank you, William.

[Richard Williams]

There is also macro drop. From the manual:

macro drop eliminates macros from memory, although it is rarely used because most macros are
local and automatically disappear when the program ends. Macros can also be eliminated by defining
their contents to be nothing using global or local, but macro drop is more convenient.

Typing macro drop base* drops all global macros whose names begin with base.

Typing macro drop all eliminates all macros except system macros—those with names that
begin with “S ”.

Typing macro drop S * does not drop all system macros that begin with “S ”. It leaves certain
macros in place that should not be casually deleted.

[daniel klein]

A few words of caution if I may.

I see people using global macros for precisely the purpose outlined here (i.e. defining various paths to folders) and I see them doing so for the exact same reasons. I would argue that global macros should only be used if something really needs to be visible globally, i.e. to others (do-files, programs, etc.). They should not be used as a substitute for local macros, i.e. used in the same way, just to be able to execute only part of the code.

One reason has more to do with the general work-flow than with the local vs. global thing. When you run parts of a do-file, you are typically not producing any final results (or at least you probably should not be, as those would probably be hard to replicate). It is hard to see why you would want to save such partial results to disk, permanently. In such a situation I personally would view any syntax errors arising from undefined local macros as a reminder to think about what I am actually about to save here. If you put replace options to your save commands just for convenience (as people typically do) you might risk overwriting valid results with partial results without even realizing.

The second reason is more closely related to the practice of defining global macros as substitutes to locals. When you later decide to call your do-file (or more than one of them) from another (master) do-file, you need to remember the global macros you have set in any of the single files you call. Otherwise you risk to change the paths to folders set in one file by defining the same global in another without realizing. If you (or colleagues that might contribute do-files to your project) drop global macros in their code, you run into similar problems. Consequences can range from broken code that will just not run to producing wrong results in the first place or overwriting results. The thing to remember is this: what is visible from outside can be changed from outside - maybe unintentionally.

For a more elaborated way of managing projects have a look into project (Picard, SSC).

Best
Daniel

[Christophe Kolodziejczyk]

I put global macros for paths in profile.do. You can also use include with locals containing paths.