Nick, this seems to work. I had actually considered this but thought
it wouldn't work. My colleague's situation seems identical to mine
except for a name change so I'm still mystified as to why the extra
quotes are required for her but not for me.
But as you and Rich suggest, it's undoubtedly safer to use the double
quotes and I will do so in future.
My colleague asked me to pass on her thanks and I wish to do likewise.
Cheers
Joseph
On Tue, Feb 17, 2009 at 8:49 PM, Nick Cox <[email protected]> wrote:
> I doubt that the problem here is anything to do with temporary files as such, or write access. My guess is that it is the handling of filenames that include spaces. However, I can't reconcile all your reports.
>
> Stata asks you to bind entire filenames like that given in " ", so that it sees each such name as one token.
>
> . save "`one'", replace
>
> The help for -save- documents this need:
>
> "If your filename contains embedded spaces, remember to enclose it in double quotes."
>
> The use of a macro here is perhaps what confused you, or something that may have contributed to your confusion. The key point is that -save- sees the contents of the macro after interpretation. So although the macro name is one word, and can only be one word, that is irrelevant to the principle, as -save- never sees the macro name as such.
>
> As said, I can't make sense of the conflicting evidence here, but using " " should do no harm and may well be the root cause of your difficulty.
>
> Nick
> [email protected]
>
> Joseph McDonnell
>
> A colleague has a problem creating a temporary file. When I run the
> following do file (on a shared network drive, not my own C: disk)...
>
> . clear
> . set obs 10
> . gen n=_n
> . list in 1/5
> . tempfile one
> . save `one', replace
> . exit
>
> it works perfectly well. A file is saved in "C:\Documents and
> settings\MyName\Local settings\Temp". When she runs it in exactly the
> same location, she gets the following error message
>
> . invalid 'Settings'
>
> . r(198);
>
> immediately following the "save".
>
> My first thought was that there was a write access problem. But our IT
> guy checked and said there is no difference between my rights and
> hers. He then installed Stata on his machine and had the same
> problem!! But when he ran Stata on our server, it worked, no problem.
>
> I'm at a bit of a loss as to why this happens. Has anyone encountered
> this problem or have a suggestion as to where we look next? We're
> using Stata 10 on XP.
>
> *
> * 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/
>
*
* 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/
