GET DATA /FILE - same directory as syntax file?
Miles
Wonder if anyone can help me - I've written a syntax file importing a
tab-delimited data file that resides in the same directory. Problem is, SPSS
doesn't seem to assume
that the data file resides in the same directory and instead looks for it in
the SPSS installation directory.
Does anyone know if there's a way to get SPSS to look for the data file in
the same directory as the syntax file?
FYI here's the syntax i'm using to import:
GET TRANSLATE FILE="data.txt"
/TYPE=TAB
/FIELDNAMES
.
... saved as syntax.sps in the same directory as data.txt - but when
syntax.sps is run, it complains that C:/Program Files/SPSS/data.txt doesn't
exist.
Any suggestions very much welcome.
Regards
Miles
Sue G
You should use a FILE HANDLE command above the GET command, as follows:
FILE HANDLE datain/name='c:\project folder\data.txt'.
GET TRANSLATE FILE=datain
/TYPE=TAB
/FIELDNAMES
"datain" is an alias for the path & filename of the datafile you
reference throughout your syntax. I routinely use FILE HANDLE for
referenced datafiles in my syntax (i.e. GET, SAVE, MATCH, ADD FILES,
AGGREGATE, etc.).
Sue
Bruce Weaver
One option is to use FILE HANDLE to define paths to folders. E.g.,
FILE HANDLE datafolder /Name ='C:\SomeFolder\data' .
All your FILE HANDLE commands could be in a separate file that is run
first, or brought in via INCLUDE FILE (or INSERT FILE). Then your GET
TRANSLATE FILE command would be:
GET TRANSLATE FILE="datafolder\data.txt"
/TYPE=TAB
/FIELDNAMES
.
--
Bruce Weaver
bwe...@lakeheadu.ca
www.angelfire.com/wv/bwhomedir
Richard Ulrich
<bwe...@lakeheadu.ca> wrote:
[snip, most of the question about using long names]
> > ... saved as syntax.sps in the same directory as data.txt - but when
> > syntax.sps is run, it complains that C:/Program Files/SPSS/data.txt doesn't
> > exist.
> >
> > Any suggestions very much welcome.
> >
> > Regards
> > Miles
> >
> >
>
> One option is to use FILE HANDLE to define paths to folders. E.g.,
>
> FILE HANDLE datafolder /Name ='C:\SomeFolder\data' .
>
> All your FILE HANDLE commands could be in a separate file that is run
> first, or brought in via INCLUDE FILE (or INSERT FILE). Then your GET
> TRANSLATE FILE command would be:
>
> GET TRANSLATE FILE="datafolder\data.txt"
> /TYPE=TAB
> /FIELDNAMES
What about LONG directory paths?
There seems to be a 64-character limit, and mine is longer,
so I quit trying. But, does the File-handle part have to be first?
How this thing is parsed is not transparent to me.
Can I set up two File Handles, for part 1 and part 2?
... file= "part1\part2\data.txt" .
Or is there another way around that 64-character limit?
--
Rich Ulrich, wpi...@pitt.edu
http://www.pitt.edu/~wpilib/index.html
Bruce Weaver
Here are answers to some of those questions.
* --------------------------------------------------- .
FILE HANDLE spssfolder /Name ='C:\Program Files\SPSS' .
FILE HANDLE GSSfile /Name ='1991 U.S. General Social Survey.sav' .
get file = "spssfolder\GSSfile".
>Error # 31. Command name: get file
>File not found.
>This command not executed.
* It appears that file handles for part1 and part2 cannot be combined.
FILE HANDLE GSSfile2 /Name ='C:\Program Files\SPSS\1991 U.S. General
Social Survey.sav' .
get file = "GSSfile2".
get file = "spssfolder\1991 U.S. General Social Survey.sav" .
* These last two work .
* Can we open a file as part1 + part2 if the two parts are macros? .
define !spss ()"C:\Program Files\SPSS\"!enddefine.
define !gssfile ()"1991 U.S. General Social Survey.sav"!enddefine.
get file = !spss + !gssfile .
* Yes, this works.
* The macro method appears to be more flexible.
* --------------------------------------------------- .
Rich, does the macro method get you around the 64-character limit?
Richard Ulrich
<bwe...@lakeheadu.ca> wrote:
> Richard Ulrich wrote:
> > On Thu, 07 Dec 2006 09:00:32 -0500, Bruce Weaver
> > <bwe...@lakeheadu.ca> wrote:
> >
> > [snip, most of the question about using long names]
[snip]
> * It appears that file handles for part1 and part2 cannot be combined.
>
> FILE HANDLE GSSfile2 /Name ='C:\Program Files\SPSS\1991 U.S. General
> Social Survey.sav' .
>
> get file = "GSSfile2".
> get file = "spssfolder\1991 U.S. General Social Survey.sav" .
>
> * These last two work .
>
> * Can we open a file as part1 + part2 if the two parts are macros? .
>
> define !spss ()"C:\Program Files\SPSS\"!enddefine.
> define !gssfile ()"1991 U.S. General Social Survey.sav"!enddefine.
>
> get file = !spss + !gssfile .
>
> * Yes, this works.
> * The macro method appears to be more flexible.
>
> * --------------------------------------------------- .
>
> Rich, does the macro method get you around the 64-character limit?
Thanks, it looks like it will, though I have tried to keep my
macro lines reasonably short - owing to odd wrap/truncate
problems in the distant past.
With a macro, I suppose I could define a string that includes
two parts, to get around line-wrap, "long_part1" + "part2".
Eventually, I'll report back.
JKPeck
working directory for the backend with a cd command
cd 'some path'.
and then SPSS will look there for files not having a full path.
If you are opening a syntax file and want to read data from that same
directory, you can use
the INSERT command, which makes INCLUDE obsolute to do it. INSERT has
an option to switch to the directory you specify for the syntax file,
so if that file reads data, it will look in the syntax file directory.
INSERT FILE='C:/myfavoritepath/powerfulcommands.sps' CD=YES.
Then a GET FILE command in that inserted file will look in
myfavoritepath if you haven't specified a full path for it.
This feature was designed for just the sort of scenario discussed here.
And, yes, file handles are a great and simple way to abstract location
out of a syntax stream. They do not have a 64 byte limitation. The 64
byte limit applies to variable names but not to literal strings.
HTH,
Jon Peck
Moshe Braner
"SUBST" to attach a "drive letter" to any folder. I then use the drive
letter in the syntax, e.g.,
get file="w:somefile.sav".
This has the advantage (over explicit paths) that I can reuse the same
syntax some other time for similar work in another folder.
Richard Ulrich
[snip]
>
> And, yes, file handles are a great and simple way to abstract location
> out of a syntax stream. They do not have a 64 byte limitation. The 64
> byte limit applies to variable names but not to literal strings.
Thanks -
About the 64+ byte name, by way of the handle --
I read error message 3013 about a limit for a "handle" of "1 to 64"
bytes, and I thought that my directory list was too long.
It turned out that when I did my cut-and-paste to make a
file handle, I wrote "File handle /name= ..." -- no handle
at all. Or, a zero-length handle, if SPSS counts the bytes.
I don't have any suggestion for what the error message should say,
but I think it could be improved.
Thanks, again.
JKPeck
contents - must be <=64 bytes, just as variable names are limited to 64
bytes.
But in the current version of SPSS (15), various synax errors produce
messages like this:
file handle /name='xyz'.
or
file handle.
>Error # 3017 in column 13. Text: /
>The FILE HANDLE command is missing the value part of a subcommand. The
>general subcommand syntax is: <keyword> = <value>. Note that the handle
>itself is treated as though it were a value. Error scanning resumes at the
>next slash.
file handle fred /name=''.
>Error # 3014 in column 24. Text:
>The FILE HANDLE command specifies an invalid file name. The file name must
>be enclosed in quotes and must not exceed the limit of 255 characters.
file handle 'abc' /name='xyz'.
>Error # 3013 in column 13. Text: xyz
>The FILE HANDLE command specifies an invalid handle. The handle must be an
>alphanumeric name from 1 to 64 characters long.
It's often tricky for a parser to figure out exactly where the error is
in an erroneous command, but I have clarified the text of 3013 a bit.
HTH,
Jon Peck