Taking currently running do file's filename as local or global

[James Park]

I want to display currently running do file name while running a do file.

Something like this, although it doesn't need to be exactly like this:

local current_do "currently running do file name"
display `current_do'

These two links seemed to be saying that the command "project" can do this.

Obtain name of current do-file - Statalist
Re: st: Working with the name of the do file (stata.com)

So I installed the "project" command by running "ssc install project"

But even if I read "help project", this command seems quite complicated and I can't see how to use this to do what I want.

Do you have any idea? I don't necessarily need to use the project command. Anything works.

[Leonardo Guizzetti]

Duplicate post here. Please put replies here.

Stata doesn't have the ability to dynamically get the current do file name or it's path. You will need to add these as local or global macros to your do file. A more efficient method is to load common paths a config file that you load at the start of the do file, then in each do file you can simply add the file name and augment with the loaded path macros as needed.

[James Park]

Duplicate post here. Please put replies here.

Stata doesn't have the ability to dynamically get the current do file name or it's path. You will need to add these as local or global macros to your do file. A more efficient method is to load common paths a config file that you load at the start of the do file, then in each do file you can simply add the file name and augment with the loaded path macros as needed.

I cannot understand what you mean because it's too technical, but I suspect I didn't explain my intention clearly.

Perhaps my words "currently running" caused a confusion.

I just meant "this do file" when I said "currently running". It doesn't need to dynamically change.

What I meant was this

[Leonardo Guizzetti]

Hi James,

I understood what you meant, and I apologize for making a more technical post than your current level of understanding. The short answer to you question is, you must hard-code the filename into the do-file. Stata is not yet "aware" which file is running the code, and so it cannot be "aware" of the file name being used. The simplest way to do this is to:

local this_do "test"
di "`this_do'"

Now I can elaborate on what I was describing in #2. Suppose you have one or a collection of do-files that make up your project. There is likely to be some information, such as configuration details, that would be used by one file or shared amongst the many files you have. In this case, you can add one file to your project that stores this common information -- let's call it config.do. This type of arrangement is often called a header file, config file, etc, but the common idea is to collect common things together in one place, so that if any changes are needed later one, they only need to be changed in this one file.

Here is the contents of config.do for this example. It contains two local macros.

local project_path "/path/to/my/project/files"
local extra_info "add things to the header that can be useful in multiple do files"

Here is an example of how you might use this config.do in one of your project files. I've called it my_script.do, and I have placed these files into the same directory.

qui include "/path/to/my/config.do"
cd "`project_path'"

di "My project path is set to: `project_path'"
di "Some extra info: `extra_info'"

When I run my_script.do, it will include the contents of the config.do file at that location (as if you had copied the text directly), and then it will proceed. First we change the directory to your project path. Then we display some information, making reference to the local macros that we defined in config.do.

This output looks like:

. qui include "c:/tmp/test/config.do"

. di "My project path is set to: `project_path'"
My project path is set to: /path/to/my/project/files

. di "Some extra info: `extra_info'"
Some extra info: add things to the header that can be useful in multiple do files

This may seem a bit overkill for simple projects, and it may be to your taste. However, in larger projects with more complexity or as the collection of do-files grows, using this concept is essential to efficient organization.