Global macros for directories with spaces

[Matt Piszczek]

Dear Form users,

I have found a few threads on the topic but nothing that I could get to work.

I am working with remote data that requires the use of global macros for the directory. I submit my .do files and they send the .log files back to me. I have recreated the directories on my home computer with test data and am trying to replicate the global macros so I can test my code before submitting it remotely.

For example, all my .do files are stored in a folder that must be named "prog" and is called up using the following:

do $prog/example01.do

The challenge is that I have spaces in the directories in my home computer. For example, I would try to use:

global prog "C:\Users\default\Dropbox\Documents\Project Name\Data Structure\prog"

I have tried a few combinations of single and double quotes to no avail. How can I get these globals to work properly? Is there a workaround for the spaces in my file structure? Using globals for directories in this manner is my only option due to the data agency's rules.

Thanks as always for your suggestions. I have been wrestling with this for longer than I care to admit!

[Clyde Schechter]

I am working with remote data that requires the use of global macros for the directory.

I really doubt that. I can't imagine what could be so special about that remote setting that you need to resort to the unsafe programming practice of using global macros there. Local macros should work just fine for holding the name of a directory and they do not risk clashing with similarly named local macros in other programs.

I think, in any case, that the question you are really asking about is how to accommodate the spaces in your pathname. As you've already discovered putting quotes around the pathname when you define the macro doesn't help. Here's what you need to do:

local prog C:/Users/default/Dropbox/Documents/Project Name/Data Structure/prog
...
use "`prog'/file_in_the_prog_directory", clear
...
export delimited using "`prog'/text_file_to_create_in_prog_directory.txt", replace
...
// OR IF YOU WANT TO JUST GO TO prog
cd "`prog'"

etc.

Note by the way the use of / as the path-separator character instead of \. Even on a Windows system, Stata will accept the forward slash in this context. And it is safer to use because in some contexts \ is interpreted not as the backslash character but as part of an escape sequence.

[Bruce Weaver]

Matt, are you saying that the following does not work?

global prog "C:\Users\default\Dropbox\Documents\Project Name\Data Structure\prog"
do "$prog/example01.do"

Clyde, I appreciate your concern about using global macros for folder locations. But using local macros for that purpose can be a bit of a nuisance while one is in the middle of developing some code. At that point, one (or at least this one) will often execute a short section of newly added code, and if that code requires a local macro that was defined somewhere near the top of the do file, it won't work unless that local command is copied to the current block of code. For that reason, I think, some people decide it's more convenient to use global macros. If one adopts some convention about how they name their global macros, and then drops them at the end of the job, that should alleviate some of the concerns about using global macros, I think. But I'll don my flame retardant suit now just in case others disagree.

[Clyde Schechter]

I know that many people feel that way, and using carefully chosen names for global macros somewhat lessens the risk. But I think the argument is very weak for the following reasons:

1. It isn't really very much work to copy and repaste the local macro name where it is needed. In fact, it's a lot less work than going back when the program is developed and replacing all of the globals with locals and changing the corresponding references from $ to `', if you really intend it only as a temporary measure during development. Also, in most circumstances, the "extra" definitions of the macro can be left in place after development anyway--they aren't necessary but usually do no harm because the macro in question wasn't modified by the code that was passed over during development. (If the code passed over during development does modify the local macro, then it would also do that to the global version, and either way, testing the later code with values of the local/global macro that are different from what it will actually be used with is also not a great idea.)

2. If a do file is so long that it gets seriously inconvenient or time-consuming to repaste them in all the places needed during development, that alone suggests poor programming style. Break the do-file up into components and then call them in order from a superordinate do file.

3. You don't even actually have to copy/paste the local macro definitions during development. You can just comment out any code that you don't want to re-run between the macro definition and where you refer to it. And in current Stata commenting out a block of code involves nothing more than highlighting it and pressing CTRL-/.

4. Finally, even adding up all the inconveniences of using local macros, you only have to get bitten by a global macro name clash once to more than make up for that. The bugs that it causes are vicious, difficult to track down, and maddening. I began my programming career back in the 1960's when all programming languages in common use had a single global namespace. And of all the causes of bugs, name clashes between data structures in different routines were often the most difficult to find and fix. Yes, global macro name clashes don't come up that often (in part because nowadays people are aware of the problems and most try to minimize or mitigate their use, especially when writing code that others will modify or use), but when they do, they're awful. Using local macros instead is a very cheap insurance against that.