while it is probably good in general to follow the rules Nick mentions,
for me
****
tempfile one
save `one', replace
****
saves a tmp-file in c(tmpdir).
****
di "`c(tmpdir)'"
****
returns
C:\DOKUME~1\myname\LOKALE~1\Temp/
so apparently long folder names holding spaces are shortened.
could this make the difference in the cases mentioned?
best, rich
"Nick Cox" <[email protected]>
Gesendet von: [email protected]
17.02.2009 12:20
Bitte antworten an
[email protected]
An
<[email protected]>
Kopie
Thema
st: RE: A problem with temporary file
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/
