it expects to be called directly from the prompt; the arguments / environment is different when sourced from inside another script. Instead just extract the relevant lines from that script and copy and paste them into your .tcshrc
Doesn’t this defeat the entire purpose of having thisroot.csh in the first place? This script is ~100 lines long. If it is meant to be called from the prompt, that means in order to do
source /pathtorootv1/bin/thisroot.csh
one has to remember /pathtorootv1. It is nice to be able to set up a default environment in .tcshrc with ROOT so that one doesn’t have to remember the path to ROOT every time a new terminal is opened. It is also nice to be able to do so in a single line so that one only has to comment out a single line if one wants to not load ROOT by default at all, and so that when one goes to change the default ROOT version there is only a single line to edit in .tcshrc.
In the trunk (revision 42926 and above), thisroot.csh has been upgraded so that it can be used non-interactively (i.e. sourced from another script) by doing: cd /pathtorootv1; source bin/thisroot.csh
or
source /pathtorootv1/bin/thisroot.csh /pathtorootv1Cheers,
Philippe.
In the trunk (revision 42926 and above), thisroot.csh has been upgraded so that it can be used non-interactively (i.e. sourced from another script) by doing: cd /pathtorootv1; source bin/thisroot.csh
or
source /pathtorootv1/bin/thisroot.csh /pathtorootv1Cheers,
Philippe.[/quote]
Greetings,
Three years later, I am finding this not to be the case. I’m trying to source a script that sets up the environment for Geant simulations, including the root variables. The recipe was developed by someone else to run in bash at CERN, I’m running tcsh at Fermilab. So I had to write a “g4env.csh” equivalent script that does a “source /afs/cern.ch/…/root/bin/thisroot.csh”.
However, it doesn’t work. When I “set verbose”, I see this:
set ARGS= ( $_ )
set ARGS= ( source g4env.csh )
if ( "$ARGS" != "" ) then
if ( source g4env.csh != ) then
set thisroot="`dirname ${ARGS[2]}`"
set thisroot=`dirname g4env.csh`
dirname g4env.csh
else
else
So clearly ARGS is set to the command line arguments of the parent script. How can this be fixed?
I think that if “thisroot.csh” is used interactively it should give priority to ARG[2], since the user specifies it; he/she clearly intends for it to be used. However, just as clearly this can’t work if thisroot.csh is embedded in a script, since ARG[2] doesn’t get set properly by csh.
One way to distinguish between the two is to check ARG[1] (assuming ARG[0]==source) to see if it contains “thisroot”. One wouldn’t expect a thisroot to be nested within another thisroot. So if ARG[1] is not thisroot, assume you are in a nested script situation and perform the “/usr/sbin/lsof”.
I suppose it would work. My assumption was that the result of lsof would be the right information in both case. Why is that not correct in the interactive case?
Well, take my attempts to test your changes for example. I don’t have my own root installation to test against. And obviously I don’t have write permission to replace “thisroot.csh” in official release areas. So I want to provide the path to a release area as an argument using “thisroot.csh” in a directory that contains no other root files.
…but then I guess I can’t do a thorough job of testing all the possible paths through your logic anyway.
For instance, I could change the name of the script, but then I’d be testing a different path through the code.
What are “@bindir@” and “@libdir@” supposed to evaluate to? On cmslpc-sl6, they don’t seem to evaluate to anything. They don’t look like valid csh syntax…
Every time I run thisroot.csh it prepends another “@libdir@” to the front of the LD_LIBRARY_PATH.
The file in config is ‘only’ a template. The @…@ variable get replaced by the configure step. Compare with the file in $ROOTSYS/bin which is the one resulting from the configuration step.
So is it possible to patch the existing release areas on /afs/cern.ch/sw with this new thisroot.csh? I know this breaks all sorts of rules for good configuration management, but…?
Or barring that, just the one I’m interested in?
/afs/cern.ch/sw/lcg/app/releases/ROOT/5.34.18/x86_64-slc6-gcc46-opt