profile.do tips

Gabi over at The Stata Things posts a neat Stata trick using a profile.do file, which is a file with commands that are run each time you start Stata. You place some commands into a file, name it profile.do and then make sure that it’s in a location on your computer that Stata knows where to look for it. When Stata starts, it scans the following locations in order:

  1. Directory where Stata was installed;
  2. Current directory;
  3. along your Unix (or Mac) PATH or in your HOME directory on Windows;
  4. along the adopath.

I have my profile.do saved in ~/ado/personal/, which is as good a place as any. In my profile.do file, the only task I keep is to set boost the memory up to a few gigs since I have plenty of memory on my computer and I don’t like dealing with lack of memory errors. This is simply:

set mem 2048m

Gabi uses his profile.do file to log all commands to a file with the current date as a name so that he can review his interactive commands and copy-paste them into a do-file or ado program later – a good plan. I used to log all commands and output to a file using profile.do using this code:

*Start logging
local d = "$S_DATE"
cap log close
cap log off
cap log using "${LOG}$S_DATE.smcl"

Ultimately, I decided to drop this from my profile.do file because the log files were getting huge and I had to keep going in to clean things up. I also never found myself using the logs.

Another trick that I used for a time was to set a bunch of global variables every time that Stata starts and use that for setting directory locations that I’d commonly use. For a while I was putting all my Stata work into one directory which was further broken down into sub-folders for raw data, logs, do-files, output, graphs, etc. This is what that code looked like:

* set global folder locations
global SOURCE "/home/andrew/Dropbox/Stata/"
global RAW "${SOURCE}raw/"
global LOG "${SOURCE}log/"
global DO "${SOURCE}do/"
global GRAPH "${SOURCE}graph/"
global OUTDATA "${SOURCE}outdata/"
global OUTPUT "${SOURCE}output/"
global WD "${SOURCE}wd/"

Then anytime I wanted to load a raw data file called data.dta I’d type in:

use "${RAW}data.dta", clear

I ended up dropping this bit from my profile.do file as well as the number of projects I worked on exploded and the files in each of these folders got crazy. Now I have a projects folder with subdirectories by project.

I’m sure there are all kinds of other profile.do hacks out there, so if you have one, please share in the comments or by e-mail.

Some additional posts on profile.do use are at the links below. Check them out!

Good luck!

This entry was posted in Uncategorized and tagged . Bookmark the permalink.

4 Responses to profile.do tips

  1. Nick Cox says:

    Evidently you only want stuff in profile.do if it’s stuff you really do want as your default, or even always.

    Extra candidates are

    0. Setting decimal point to be comma (standard in many countries, but not for me).

    1. Your favo[u]rite graph scheme.

    2. Net i/o settings. Some users will need to customise this trio

    set httpproxy {on|off} [, init]
    set httpproxyhost ["]name["]
    set httpproxyport #

  2. andrew says:

    Thanks Nick. Although I’ve never had reason to use something like numbers 0 or 2, I could see how they could be very useful. As there probably aren’t many who can boast more Stata knowledge/experience than you, are there any other profile.do uses you’ve seen that could be handy?

  3. Nick Cox says:

    As above, I am wary of recommending generally what anyone in particular does. Perhaps the main extra advice is to reflect on whatever you tend to do in most or all sessions with Stata that could be automated in a profile.do.

    I just looked at various profile.do files and found that one extra tip is to use -adopath- to indicate extra places to look for programs. On one network used for teaching we use part of a T: drive (doesn’t matter, but “T” stands for teaching) for extras as a matter of institutional policy; that is the kind of detail that is bound to be idiosyncratic to individual set-ups, but also the kind of detail that you definitely want to automate for student users. (Downstream you might then need to explain to people with their own Stata that the extras you installed on the network were indeed extras, but that’s a different issue.)

    • andrew says:

      I think you hit on some good points here with regards to using profile.do for teaching. Also, good to keep in mind that profile.do runs EVERY time you start Stata, so whatever’s in there better be something you want to happen every time.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>