***  For details on how to be removed from this list visit the  ***
***          CCP4 home page http://www.ccp4.ac.uk         ***



Sorry what I said previously isn't quite right, the problem is that
CCPFYP in CCP4 doesn't reset an internal environment variable to the
value defined in $CINCL/default.def if it has been set externally by the
parent process (in this case by the shell sourcing some initialisation
script).  One solution would be to run SOLVE in the same way that COOT
is currently run, i.e. using a wrapper script where all the environment
variables specific to SOLVE are set, and the environment variables in
the shell would not be affected.  Another perhaps better solution would
be to re-code CCPFYP so that SYMINFO is always reset to the value in
$CINCL/default.def regardless of whether it was set externally by the
shell: if the user then really does want to reset it (very unlikely
except perhaps for debugging purposes), it could be done by:

program_name SYMINFO filename ...

I think there is a good argument for saying that all variables with
default values in default.def such as SYMINFO should be ignored by
CCPFYP if they have been set in the external environment rather than the
command line, as it's possible that these variables could be set
unintentionally by the user.  Other variables which have no default such
as CLIBD obviously have to be passed in from the external environment.

-- Ian

> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> Behalf Of Ian Tickle
> Sent: 09 January 2007 10:16
> To: Santarsiero, Bernard D.
> Cc: [email protected]
> Subject: RE: [ccp4bb]: SYMINFO environment variable
> 
> ***  For details on how to be removed from this list visit the  ***
> ***          CCP4 home page http://www.ccp4.ac.uk         ***
> 
> 
> 
> I don't see how this can be a problem because the SYMINFO environment
> variable is only set and used internally by CCP4 programs (by 
> the CCPFYP
> routine when the program starts), i.e. the user should not be 
> setting it
> anywhere (and it's not set by ccp4.setup).  Environment 
> variables set by
> a child process do not affect the parent process, so that when a CCP4
> program terminates all evidence that the internal variables (i.e.
> SYMINFO, HKLIN, XYZIN etc.) were set is erased.  Variables set by the
> parent process (e.g. the shell) _are_ inherited by the child processes
> (e.g. the running programs), but any changes made by the child process
> are not passed back to the parent.  Presumably the SYMINFO 
> set by SOLVE
> is a regular environment variable set by sourcing a script, 
> but it will
> not be affected by any changes made internally by CCP4 programs.
> 
> -- Ian
> 
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> > Behalf Of Santarsiero, Bernard D.
> > Sent: 08 January 2007 23:05
> > To: [email protected]
> > Subject: [ccp4bb]: SYMINFO environment variable
> > 
> > ***  For details on how to be removed from this list visit the  ***
> > ***          CCP4 home page http://www.ccp4.ac.uk         ***
> > 
> > 
> > SYMINFO is defined as an environment variable for both SOLVE 
> > and CCP4. Can
> > one of the packages change their definition of this in future 
> > releases? We
> > repeatedly need to redefine it, depending of whether we're currently
> > running a SOLVE or CCP4 job. Or is there a way around this?
> > 
> > Bernie Santarsiero
> > 
> > 
> > 
> 
> Disclaimer
> 
> This communication is confidential and may contain privileged 
> information intended solely for the named addressee(s). It 
> may not be used or disclosed except for the purpose for which 
> it has been sent. If you are not the intended recipient you 
> must not review, use, disclose, copy, distribute or take any 
> action in reliance upon it. If you have received this 
> communication in error, please notify Astex Therapeutics Ltd 
> by emailing [EMAIL PROTECTED] and destroy all 
> copies of the message and any attached documents. 
> 
> 
> 
> Astex Therapeutics Ltd monitors, controls and protects all 
> its messaging traffic in compliance with its corporate email 
> policy. The Company accepts no liability or responsibility 
> for any onward transmission or use of emails and attachments 
> having left the Astex Therapeutics domain.  Unless expressly 
> stated, opinions in this message are those of the individual 
> sender and not of Astex Therapeutics Ltd. The recipient 
> should check this email and any attachments for the presence 
> of computer viruses. Astex Therapeutics Ltd accepts no 
> liability for damage caused by any virus transmitted by this 
> email. E-mail is susceptible to data corruption, 
> interception, unauthorized amendment, and tampering, Astex 
> Therapeutics Ltd only send and receive e-mails on the basis 
> that the Company is not liable for any such alteration or any 
> consequences thereof.
> 
> 
> 
> 
> 

Disclaimer

This communication is confidential and may contain privileged information 
intended solely for the named addressee(s). It may not be used or disclosed 
except for the purpose for which it has been sent. If you are not the intended 
recipient you must not review, use, disclose, copy, distribute or take any 
action in reliance upon it. If you have received this communication in error, 
please notify Astex Therapeutics Ltd by emailing [EMAIL PROTECTED] and destroy 
all copies of the message and any attached documents. 



Astex Therapeutics Ltd monitors, controls and protects all its messaging 
traffic in compliance with its corporate email policy. The Company accepts no 
liability or responsibility for any onward transmission or use of emails and 
attachments having left the Astex Therapeutics domain.  Unless expressly 
stated, opinions in this message are those of the individual sender and not of 
Astex Therapeutics Ltd. The recipient should check this email and any 
attachments for the presence of computer viruses. Astex Therapeutics Ltd 
accepts no liability for damage caused by any virus transmitted by this email. 
E-mail is susceptible to data corruption, interception, unauthorized amendment, 
and tampering, Astex Therapeutics Ltd only send and receive e-mails on the 
basis that the Company is not liable for any such alteration or any 
consequences thereof.



Reply via email to