[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]

Re: st: Capturing the directory of a .do file

From   "Sergiy Radyakin" <[email protected]>
To   [email protected]
Subject   Re: st: Capturing the directory of a .do file
Date   Fri, 7 Sep 2007 11:39:20 +0200

Hello Matthew,

Generally it is not possible to retrieve a .do file's name from
itself. Search for "st: Does a do file know its own name?" Though this
feature is being awaited by many. It seems to be quite standard in
other languages, and even archaic DOS batch files had it
up-and-running: "%0 is the program name as it was called"

However for Stata for Windows a small patch was created:

It will only work if a .do file is launched from Windows Explorer, but
might also work with some file managers, e.g. it works with Total
Commander. It definitely does not work with the Stata do-editor.

Inside a .do file its name is available in ${DO_NAME}

To open a log file with the same name as a do file use -subinstr- to
replace ".do" to ".log" in the file name and use the result as a
log-file name.

No warranties expressed or implied. Tried it on one single
configuration (and it worked) so there might be surprises of course.
See site for details.

If you don't want to apply the patch:

1. One way would be to create an installer ado file, which would do
all the administrative work for you (e.g. create directories, download
packages, create configuration files, etc). If Stata had an autolaunch
capability (also discussed before) it might have been able to start
automatically, but so far the user has to launch it. At this point you
don't have to stick to Stata. You can write your installer in Asm,
Basic, C, Delphi, ... (alphabetic :) or use one of a Zillion of
precooked installers. (Note however, that It seems to be customary in
Stata community NOT to ask the user, where to install the modules.
They just end up somewhere along the adopath. Stata can see it, and
nobody cares...)

2. If it is your program that uses those macros (not the user program)
you can check if those macros are defined, and if not -- show a
message box to a user with explanations.

3. You may want to think about the logic of your programming
environment (e.g which program calls which) and may be explain a bit
to us. Perhaps it makes sence to launch your program first, which will
ask the user at a cirtain point "Which project would you like to run?"

4. Use wrappers, as described earlier.

2Austin: Why not just use relative paths, and have folks run the do-file in the
relevant starting directory? Because when a .do file is run, current
directory is not necessarily the directory where the .do file is
located. So the relative paths will be derived from the wrong starting

Best regards,
   Sergiy Radyakin
*   For searches and help try:

© Copyright 1996–2024 StataCorp LLC   |   Terms of use   |   Privacy   |   Contact us   |   What's new   |   Site index