Statalist


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

Re: st: I can't get fs to work from inside a do file


From   "Gabi Huiber" <[email protected]>
To   [email protected]
Subject   Re: st: I can't get fs to work from inside a do file
Date   Sun, 17 Feb 2008 20:45:19 -0500

Michael,

Thank you for replying to my post. Below is an actual copy of my Stata
results window, after the do-file with the fs command rolled to the
end without executing. Remember that we started here:

. ***************** 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"

end of do-file

So I went to the command window and copied the fs line into it, as shown below:

. fs prototype/${paper}/*.do
dna_step1_target.do     dna_step3_report1.do    dna_step5_report2.do
dna_step2_snapshot1.do  dna_step4_snapshot2.do

Clearly, it worked. Next, I declared the local eenie:

. local eenie r(files)

Then I checked to see that it showed what I thought it would:

. di `eenie'
"dna_step1_target.do" "dna_step2_snapshot1.do" "dna_step3_report1.do"
"dna_step4_snapshot2.do" "dna_step5_rep
> ort2.do"

And it did, but look:

. local x: word count `eenie'

. di `x'
1

Even though `eenie' seems to have five distinct words delimited by
quotes, it only has one. The quotes are somehow embedded in it. So I
tried evaluating the r(files) expression, like in `meenie' below:

. local meenie=r(files)

. di `meenie'
dna_step1_target.dodna_step2_snapshot1.dodna_step3_report1.dodna_step4_snapshot2.dodna_step5_report2.do

Now the thing clearly looks like it's one uninterrupted word, but it's
not. Look:

. local y: word count `meenie'

. di `y'
5

So with the risk that it would truncate the content of the ${paper}
folder to 244 characters, using the = sign looked like a good idea at
the time. Now I will move on to trying out Joseph Coveney's syntax and
see how that works. The 244 character limitation is not binding now,
but it might be in the future. I want to avoid it if I can. This reply
was just for the entertainment of the interested parties. I think it's
at least curious how Stata looks like it does one thing, and does
another.

Thanks again to all,

Gabi


On Feb 16, 2008 4:48 PM, Michael Blasnik <[email protected]> wrote:
> ...
>
> I hope you realize that your line
>
>  local dofiles r(files)
>
> simply places the text string "r(files)" into the local macro dofiles.  That is
> why word count comes up with one word.  You need to expand the local macro when
> assigning it to dofiles, like this:
>
> local dofiles `r(files)'
>
> If you use the equals sign, then the list will be truncated at 244 characters.
> Without the equals sign it is nearly limitless.
>
> Michael Blasnik
>
>
> ----- Original Message -----
> "Gabi Huiber" wrote:
> >If you do
> >
> > local dofiles r(files)
> >
> > you get a string of all their names in a single word. I checked with
> > word count `dofiles'. That, of course, defeats the foreach loop. It's
> > bizarre, because this single-word string shows the do-file names
> > neatly delimited with spaces, whereas if you do
> >
> > local dofiles=r(files)
> >
> > like I did, the do-file names in that folder look like they're all
> > strung together as in file1.dofile2.do[...] yet the local `dofiles'
> > does have five distinct words, one for each do-file, as it should. Try
> > it with one of your do-file directories to see what I mean. Of course
> > running the foreach loop directly off the `r(files)' local fixes the
> > problem, but it's still a strange one, don't you think?
>
>
> *
> *   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/



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