I apologize. I checked for everything you suggested, but was not
explicit. In addition, you're right: fs works, no qualifiers. So for
completeness, here:
I know that enclosing file paths in double quotes can't hurt, and it
occurred to me that it would be a good habit to cultivate. But I never
did. Instead I stuck with path and file names that would have no
spaces, and Stata always rolled along without the double quotes. In
this case too, ${paper} had the value DNA, so the true path was
/prototype/DNA/. However, the ${bigroot} directory did have a space in
it, because it was "D:/Shared Files/[...]"
So, about your first suggestion: I thought, like you suspected, that
the lack of double quotes didn't hurt anything, since I had no spaces
in the file path. Nonetheless, after your reply below I did put them
in. I was surprised to see that the thing worked without the need to
change directories. This made me suspect (on to your second
suggestion) that the double quotes, while usually optional, are
required by Stata's dir command, and fs just serves up what dir wants.
But I was wrong. According to the help dir page, the double quotes are
not required if there are no spaces in the file path. This leaves one
possibility: no spaces means no spaces at all, all the way to the
letter drive. Even if there are no spaces in /prototype/DNA/, as long
as this branch springs from "D:/Shared Files/[...]" dir will require
double quotes, and so will fs. Now I am also convinced that the habit
of double quotes always would have been a good one to have. If you're
using globals like ${paper}, you can have human-readable file paths.
Double quotes would ensure that they are Stata-readable too.
So, fs works as advertised. My apologies, again.
Michael:
Thank you for clearing up this `r(files)' issue. It's been escaping me
for years.
Gabi
On Feb 18, 2008 3:25 AM, n j cox <[email protected]> wrote:
> I am pleased you got what you want, but you leave -fs- with one positive
> compliment and one negative comment that it "can't read file paths very
> well". As program author, I can't address that comment until you address
> the suggestions in my email, which you quote but do not discuss.
>
> You don't address this
>
> ===================================================================
> 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"
> ====================================================================
>
> or this
>
> ===============================
> Presumably you have checked that your current working directory in the
> interactive session and that for the do file are the same.
> ===============================
>
> As you report that -cd- did the trick, that leaves me with a hunch that
> the problem lies not in -fs-, but in the information you feed to it.
>
> Also, Stata does have a command to do what you want, as emphasised.
>
>
> Nick
> [email protected]
>
> Gabi Huiber
>
> 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/
