I am happy to report that cd did the trick, as Joseph suggested it
would. Nick's fs comand is yet another great way to automate Stata
processes. Writing solutions in this modular form, where do-files call
other do-files, has several advantages when you're moving from
prototype to production. It allows for recycling code, for expanding
it as needed, and for an easier way to follow the logic of why you're
doing what you're doing.
If you must call other do-files, it's nice to not have to spell them
out. At different versions of your project or iterations of a loop,
the number and names of do-files you need to call can change, so you
cannot hope to spell them out. Fs takes care of that. It just can't
read file paths very well. So as Joseph suggested, you may have to do
this:
cd prototype/${paper}/
fs *.do
cd "${bigroot}"
foreach k in `r(files)' {
do "prototype/${paper}/`k'"
}
clear
di "goodbye"
Works well enough for me, but I'm surprised that there is no
equivalent command in standard Stata.
Gabi
On Feb 17, 2008 11:49 AM, n j cox <[email protected]> wrote:
> Gabi Huiber sent in a question about my -fs- (downloadable from SSC) and
> Joseph Coveney and Michael Blasnik gave various good advice. I didn't
> see in the thread following any details on what kind of values the
> global ${paper} might take on.
>
> If that global included embedded spaces say "foo bar", then
> after macro substitution the command line would read
>
> fs prototype/foo bar/*.do
>
> and Stata's standard command line processing would cause -fs- to see two
> arguments
>
> prototype/foo
>
> bar/*.do
>
> and you might well find that no such files are reported to exist. As
> always the remedy for that is to bind the argument in double quotes, as
> in
>
> fs "prototype/${paper}/*.do"
>
> and in any case that should do no harm. However, it does seem unlikely
> that this is biting, as you can get it to work in some cases and not
> others.
>
> Presumably you have checked that your current working directory in the
> interactive session and that for the do file are the same.
>
> Beyond that, my only suggestion is to remember that -fs- is just a
> wrapper. Trying the underlying Stata command might help identify whether
> you have found a bug or limitation in -fs- or a bug or limitation in the
> underlying command, in this case
>
> local files : dir "prototype/${paper}" files "*.do"
>
> Some time I ago I reported to StataCorp a bug in -: dir- which underlay
> what had been reported to me as a bug in -fs-. I don't know if it was
> ever fixed.
>
> Nick
> [email protected]
>
> Gabi Huiber
> ===========
>
> Nick Cox has this little command called fs, which reads the files in a
> certain folder and remembers them in r(files). I tried to use it to
> run a bunch of do-files from inside a root do-file, because the name
> and number of these subsequent do-files can vary between the
> sub-folders of interest. So here's what I did:
>
>
> . ***************** CALL DO-FILES SPECIFIC TO EACH ${paper} HERE
> .
> . fs prototype/${paper}/*.do
> > local dofiles=r(files)
> >
> > foreach k of local dofiles {
> > do "prototype/${paper}/`k'"
> > }
> >
> > clear
> > di "goodbye"
>
> As you can see, Stata breezes right through the lines after fs. It
> also does not interpret fs: display r(files) shows nothing. However, I
> can copy the fs line from the results window and paste it in the
> command window, and it will execute just fine. Ditto for all the lines
> below it.
>
>
> *
> * 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/
>
*
* 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/
