On Sun, Sep 5, 2010 at 9:12 PM, Michael Evans <evan...@illinois.edu> wrote:
Now for the real reason for my e-mail: I want to make sure I understand
"write state REMOTEPATH" and "write state LOCALPATH." Can I specify, for
instance, "../structures" to replace all the file references in a state file
to a directory called "structures that is a sibling of wherever the file
resides? Is that how LOCALPATH works...? If I'm off base, let me know
(however if I'm on base, this is amazing and awesome).
>
>
>
Cheers, Mike
>
>
In the WRITE command after the word STATE you can add LOCALPATH "...."
and/or REMOTEPATH "...." parameters. If these are present, then all file
references in the state (load command, isosurface command, pmesh command,
etc.) will be "fixed" to your specifications. References that start with
"http://"; or "ftp://"; or maybe a few other such protocols will be converted
based on the REMOTEPATH designation; others will be converted based on the
LOCALPATH designation.
So, to answer your question: "Almost."
write STATE LOCALPATH "../structures" "myfile.spt"
will create myfile.spt with all the references to local files on your hard
disk changed to "../structures/xxxxx", but it will leave any remote
references the same.
Note that for an applet, ".." is in reference to where the WEB PAGE will be
located (or where the default path has been set to). If you want this to be
in reference to where the SCRIPT file is located, then use
write STATE LOCALPATH "$SCRIPT_PATH$/structures" "myfile.spt"
That $SCRIPT_PATH$ text will be replaced by the actual script file path when
the script is run, wherever it is.
Also, note that you can just create states the normal way, without LOCALPATH
and REMOTEPATH and then instead use
script LOCALPATH "...." REMOTEPATH "..." ...
on the script-reading end of the operation to set those at that point to
anything you want.
Bob
--
Robert M. Hanson
Professor of Chemistry
St. Olaf College
1520 St. Olaf Ave.
Northfield, MN 55057
http://www.stolaf.edu/people/hansonr
phone: 507-786-3107
If nature does not answer first what we want,
it is better to take what answer we get.
-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users
