Executing Sendlines changes STATA's working directory

[danachandler]

This extension is so wonderful that I feel bad giving any criticism. Please take this criticism as a compliment and feeling of indebtedness to provide feedback.

Whenever you send files to stata, it changes the working directory of STATA to the working directory of the do file you executed. This is undesirable because many do files make use of relative references. For instance, I execute code from a do file in /project_name/code/ folder, but like to save graphs to /project_name/graphs. Ordinarily, I would navigate to project name and then export the graph to graphs/graph_name.png. However, since the do file causes STATA's working directory to move to project_name/code/, my relative reference to where I want to save the graph is incorrect.

One workaround is to define the directory name of the project to a variable such as project_directory and write out the desired output location as project_directory/graphs/.

Additionally, is there a reason that the sublime2stata.do file isn't deleted after executing the script? If it worsens performance, it's probably not worth fixing, but if it's just adding a line of code, that would probably be best.

[danachandler]

Upon further inspection, I don't think setting a local macro with the file directory works either :( For blocks of code that reference outside files, I think you either have to write out the actual directory, or if you set a variable, you may have to run the lines by copy/pasting.

I haven't fully explored workarounds to the bad behavior, but will post any solutions/further observations if I find them.

[andrewheiss]

Hrm. That seems to be a Stata-specific problem, since it should happen any time you run any .do file like this (i.e. double clicking on it and opening it in Stata). I wonder if there's some way to tell the do command to not change the directory. This seems like it would be important for Stata to do, especially if you automate it with Makefiles or something—shouldn't it respect the working directory and not mess around with it?

The sublime2stata.do file isn't deleted because I didn't want it to be when I was working on the plugin, since I wanted to make sure it was getting the right stuff from ST. A previous version of this plugin (made by someone else) actually made a .sublime2stata.do that was hidden, but I wasn't a fan of littering my computer with old hidden files. It's trivial (one line!) to delete it, so I'll do that.

[andrewheiss]

Actually, look at known problem #5 here. It's for Notepad++ on Windows, not Stata on OS X, obviously, but it might be the same problem. What happens when you open Stata on your own or set the working directory manually? Does that change anything?

[danachandler]

re: deleting the sublime2stata.do file..... awesome!

re: the way directory references seem to be breaking, I'll see if I can fix that or at least provide a reproducible example.

-Dana

On Wed, Mar 19, 2014 at 2:19 PM, Andrew Heiss [email protected]:

Hrm. That seems to be a Stata-specific problem, since it should happen any time you run any .do file like this (i.e. double clicking on it and opening it in Stata). I wonder if there's some way to tell the do command to not change the directory. This seems like it would be important for Stata to do, especially if you automate it with Makefiles or something--shouldn't it respect the working directory and not mess around with it?

The sublime2stata.do file isn't deleted because I didn't want it to be when I was working on the plugin, since I wanted to make sure it was getting the right stuff from ST. A previous version of this plugin (made by someone else) actually made a .sublime2stata.do that was hidden, but I wasn't a fan of littering my computer with old hidden files. It's trivial (one line!) to delete it, so I'll do that.

Reply to this email directly or view it on GitHubhttps://github.com/andrewheiss/SublimeStataEnhanced/issues/11#issuecomment-38087775 .

[andrewheiss]

So, it turns out that deleting the .do file is a little less trivial than I thought. Actually deleting it takes one line of code and is super simple. The problem, though, is that it gets deleted before it can open in Stata. Here's the workflow as it stands now:

1. Invoke the plugin. Plugin script starts running.
2. Write the selected lines to the temporary file.
3. Use AppleScript to open the temporary file in Stata.
4. Plugin stops running.
5. Eventually the file runs in Stata. If Stata wasn't open initially, it has to go through all the startup stuff and open. Could take a few seconds

Deleting the temporary file is trickier though. It won't work if I do this:

1-3. Same 4. Delete file 5. Plugin stops running 6. Stata eventually opens, but the temporary file is gone, so nothing happens.

I could put a delay in the script to give Stata time to open before deleting:

1-3. Same 4. Wait for X seconds 5. Stata opens 6. Delete file 7. Plugin stops running and focus returns to ST

But this has two problems: (1) X is hard to set, since newer computers with SSDs will open Stata instantly, while older ones might take a dozen+ seconds, and (2) there's a delay between actually sending the line, having it run in Stata, and returning focus to ST. It feels really slow and clunky.

This is probably why past iterations of this plugin just made the temporary files hidden, since deletion takes a lot of coordination. But I'm not a fan of littering peoples' computers with hidden temporary files, so I think for now it's best to keep it as is. People can delete the temporary do file as needed.

Perhaps in the future it might be useful to write to the system temporary folder (in /tmp or whatever OS X uses), so these files periodically get cleaned up. But if Stata consistently changes the working directory to the path of the temporary do file, that might not be helpful.