Hi,
We have a lot of code that contains relative paths, e.g.:
save outfile = "somefile.sav"
save outfile = "..\..\somefile.sav"
save outfile = ".\somefile.sav"
I always prefer to use FILE HANDLEs, ie symbolical names that refer to UNC paths (not drive letters!). That avoids confusion about wat the working directory is. But will something like the following syntax that uses the CD command always behave as expected (ie, in SPSS > v15, in SPSS Server)? Even though file names are scattered throughout the syntax, this is still a fairly clean looking code.
FILE HANDLE outpath /NAME = "file://server/share/folder/subfolder".
PRESERVE.
CD outpath.
.. code...
SAVE OUTFILE = "somefile1.sav".
.. more code...
SAVE OUTFILE = "somefile2.sav".
.. more code...
SAVE OUTFILE = "somefile3.sav".
RESTORE.
Here is some information about relative paths
http://publib.boulder.ibm.com/infocenter/spssstat/v20r0m0/index.jsp?topic=%2Fcom.ibm.spss.statistics.help%2Func_path.htm
https://www.ibm.com/developerworks/mydeveloperworks/files/app/person/270003ERMT/file/bdac73ed-38c5-4df1-9a76-546734c5bcc7 Regards,
Albert-Jan ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ All right, but apart from the sanitation, the medicine, education, wine, public order, irrigation, roads, a fresh water system, and public health, what have the Romans ever done for us? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
The CD approach will work, and note the
CD feature on INSERT, but it's easy to lose track of it if the CD isn't
close to the code that uses the working directory. And, of course,
with either approach the backend working directory is not necessarily the
same as the frontend, which would be running on a different system in distributed
mode with Server, so there is some room for confusion.
So my preference is to be explicit with FILE HANDLE. Particularly in situations where you might now or in the future want to separate, say, data and code. Giving these different handles leaves open future reorganization. One other note: if you use tools like SPSSINC PROCESS FILES, it gives you a whole set of file handles and macros defined externally to the specific syntax being run. Jon Peck (no "h") aka Kim Senior Software Engineer, IBM [hidden email] new phone: 720-342-5621 From: Albert-Jan Roskam <[hidden email]> To: [hidden email] Date: 08/15/2012 06:28 AM Subject: [SPSSX-L] relative paths -should they NEVER be used? Sent by: "SPSSX(r) Discussion" <[hidden email]> Hi, We have a lot of code that contains relative paths, e.g.: save outfile = "somefile.sav" save outfile = "..\..\somefile.sav" save outfile = ".\somefile.sav" I always prefer to use FILE HANDLEs, ie symbolical names that refer to UNC paths (not drive letters!). That avoids confusion about wat the working directory is. But will something like the following syntax that uses the CD command always behave as expected (ie, in SPSS > v15, in SPSS Server)? Even though file names are scattered throughout the syntax, this is still a fairly clean looking code. FILE HANDLE outpath /NAME = "file://server/share/folder/subfolder". PRESERVE. CD outpath. .. code... SAVE OUTFILE = "somefile1.sav". .. more code... SAVE OUTFILE = "somefile2.sav". .. more code... SAVE OUTFILE = "somefile3.sav". RESTORE. Here is some information about relative paths http://www-01.ibm.com/support/docview.wss?uid=swg21475088 http://stackoverflow.com/questions/2966177/specifying-relative-paths-in-spss-18 http://publib.boulder.ibm.com/infocenter/spssstat/v20r0m0/index.jsp?topic=%2Fcom.ibm.spss.statistics.help%2Func_path.htm https://www.ibm.com/developerworks/mydeveloperworks/files/app/person/270003ERMT/file/bdac73ed-38c5-4df1-9a76-546734c5bcc7 Regards, Albert-Jan ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ All right, but apart from the sanitation, the medicine, education, wine, public order, irrigation, roads, a fresh water system, and public health, what have the Romans ever done for us? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
Free forum by Nabble | Edit this page |