Dear Statalisters,
I have three questions regarding the use of the shell command in Stata
for Windows. This is rather technical, and might be interested to just
a few readers, but I would really want to know the answers.
What do I need to do:
launch FooBar.exe and pass a filename to it as a parameter, wait for
it to complete and continue with my do file. FooBar.exe is a Windows
program, so it does not make any use of the terminal window, that
opens after I call the shell. Note, that I particularly don't want to
see the terminal window on the screen (even briefly).
I am aware of the use of start/start.exe commands discussed earlier in
the Statalist for a similar purpose, but I decided to pursue another
way to prevent a terminal window from appearing, namely changing the
reference to the shell, stored in the global $S_SHELL. For details,
see a technical note in [D:shell]. I know it is not recommended,
though I don't know why. My guess is that Stata just starts another
process, and waits for it to complete. If there is any particular
difference in handling cmd.exe/command.exe/command.com and any other
executable, I would wish to know more about it.
Now the questions:
--------------------------------
Q1: It turns out that
!c:\FooBar.exe parameter1
is not equivalent to:
global $S_SHELL "c:\FooBar.exe"
! parameter1
In fact FooBar gets started, but Stata adds a parameter /C as the
first parameter, which causes unexpected behaviour in the programs,
which
A) use parameter /C for their own needs, or
B) expect a fixed order of the parameters, e.g. filename must be the
first parameter.
What is the motivation to add /C in this case? Is there any way to
change this? Is it always the case(within and across Stata versions) /
will be always the case?
Q2:
Suppose Q1 is resolved and I substitute the chain1 to chain2:
Chain1: Stata->Terminal->FooBar.exe
Chain2: Stata->FooBar.exe
If FooBar.exe crashes in chain1, nothing bad happens to Stata. FooBar
is really run as an independent process and all the other processes
enjoy isolation from it, provided by the OS.
However, in Chain2, FooBar.exe seems to be started as a child process,
rather than simply a process. A crash in FooBar.exe will cause Stata
to collapse, which is not desirable. Is there any reason to control
this, and start FooBar.exe and wait for it to complete (successfully
or not), and then continue (similarly like Windows Explorer program
(or any file manager) does not crash when the program launched from it
does crash)?
Q3:
Chain3: ProgramA->Shell->ProgramB
In the older times, (DOS times), in the chain3 (above) ProgramB could
have about 640kb-(size of ProgramA+data of ProgramA)-(command.com size
+ shell overhead) memory for it's use. E.g. running a program from
another program meant that they compete for resources. Is this the
case in Stata for Windows 32-bit now? Will FooBar.exe be able to
allocate only 2GB-StataMemoryUse for itself? Does it depend on whether
chain1 or chain2 was used to launch it?
Thank you,
Sergiy Radyakin
*
* For searches and help try:
* http://www.stata.com/support/faqs/res/findit.html
* http://www.stata.com/support/statalist/faq
* http://www.ats.ucla.edu/stat/stata/
