Dear Roger,
before the answers follow, why not instruct the users to include
Stat\Transfer into the path, and resolve the problem forever??
Alternatively, read the registry for the full path to Stat\Transfer.
You will find the appropriate value here:
HKLM\Software\Circle Systems\StatTransfer9\InstallDir
(this is the most "correct" way from my point of view, otherwise you
risk to run st.exe which does "shuttle-terminate" in NASA, or
"subway-traffic" somewhere in METRO)
Remember that not all the users will have Stat\Transfer installed at
the default path.
On 8/5/08, Newson, Roger B <[email protected]> wrote:
> I have some queries about calling non-Stata programs (eg Stat/Transfer)
> from within Stata:
>
> 1. Is there a way of verifying that a string (eg the contents of a
> macro) is a program path name, under the operating environment under
> which Stata is currently running? I am aware that we can use
>
> confirm file <filename>
>
> to confirm or deny that <filename> is the name of an existing file.
> However, a filename is not exactly the same thing as a program path
> name. For instance, under Windows, a program path name can be a program
> filename minus the .exe or .bat extension, and such a pathname will not
> pass as a filename, according to the confirm command.
To find out which directories to probe, use:
display `"`:environ PATH'"'
Parse that for semicolon (";") to separate multiple paths.
To check that a particular path exists use:
capture chdir `"`path_to_test'"'
if (`_rc'==170) display "Directory `path_to_test' is invalid"
else ....do something...
After that, you can check for a particular file in that directory.
>
> 2. Failing that, is there a way for Stata to know, and to pass to the
> user's program, information on whether a program run by the shell
> command executed successfully? (Preferably passing the return code
> returned by the operating enviromment.) The shell command does not
> appear to return anything in r(), s() or even e().
It depends: in the worst case the callee can make such a crash, that
the computer shuts down. In this case nothng can be done. In general
the callee must return the code with exit(code), halt(code),
return(code) or something similar.
Read the manual for Stat\Transfer on what codes it returns. From what
I see, when I run
st nothing.at.all
it displays license information and returns code zero. I would rather
prefer a message "file not found" and a non-zero error code.
Google %errorlevel% for details on how to handle error codes.
Expect your program to at least quadruple in size to accomodate all
these things.
By the way, what is the motivation to put statement "version 9"??? It
will not save data in version 9 format anyways, so older versions of
Stat\Transfer will not understand modern Stata 10 file format. It is
better to analyse the version of Stata and -saveold- if necessary.
Otherwise (AFAIK) the program should be able to run in version 7 at
least. Why exclude users of older Stata? Why erase a tempfile in the
end of the program? Stata does this automatically.
>
> 3. If either of these things are currently impossible in Stata, then are
> there plans to make them possible?
these things are possible. See above.
>
> I ask because users of my SSC package stcmd (which calls Stat/Transfer)
> are often confused if Stat/Transfer does not run correctly. In the next
> update of stcmd, I would like to make stcmd more helpful to such users,
> giving advice on what may have gone wrong. Currently, the best that I
> can think of is to make stcmd echo the Stat/Transfer command that it
> passes to the operating environment. However, that would be helpful
> mostly to technically-minded users, who know a bit about commands and
> the operating environment. A lot of users do not like having to
> understand commands of the kind executed in shell scripts.
>
> Best wishes (and thanks in advance)
>
> Roger
Hope this helps,
Sergiy Radyakin
*
* For searches and help try:
* http://www.stata.com/help.cgi?search
* http://www.stata.com/support/statalist/faq
* http://www.ats.ucla.edu/stat/stata/
