Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Is there a way to have STATA identify the directory that a .do file is placed?

    I have started to include a header in my .do files that reads as follows:

    Code:
    clear
    macro drop _all
    set more off 
    set type double
    global do = c(pwd)
    The global macro $do shows the directory in which the .do file is located, assuming I have opened the .do file in a new STATA console window. If instead, I open and run various other programs within the console, and then open the file with this header, it does not have the c(pwd) set to the directory where this .do file came from. Is there any command I can use to reset STATA such that after running other programs, I can open this file in the same console and have the c(pwd) set to where the .do file is located? For example, if the command was called "reset cd", I could place it in the code as follows, and the code would then always assign the .do location directory as c(pwd):

    Code:
    clear
    macro drop _all
    set more off 
    set type double
    reset cd
    global do = c(pwd)

  • #2
    I've seen questions about "reflection" (the relevant programing concept) in Stata before and suffice it to say I'm not aware of a command that does this for you in one step. I'd be glad to suggest some algorithms and data structures that should help you to do this kind of thing, but I guarantee they'd be a pain to implement properly. You might be able to find a clever way to maintain a stack for this, but I suspect you will end up needing a command that searches your file system for the content of the current do file to get the path.

    Edit: might be a way to do this with grep...

    Comment


    • #3
      The short answer is no, and this question has come up several times on the forum if you search for it. The common way people get around this, I suspect, is to specify an absolute or relative path either in the do file or an included do file so that it gets inherited by any do file referencing back to this (for simplicity this is a kind of config file approach).

      Comment

      Working...
      X