Thisroot

gadamc · 2010-12-06T10:50:31.000Z

Hi all.

When I add the ‘source /pathtoroot/bin/thisroot.csh’ to my .tcshrc file, I get the following error when I start a shell

ARGS: Subscript out of range.

And, my environment variables aren’t set properly.

When I just call ‘source /pathtoroot/thisroot.csh’ from a shell prompt, it works fine.

I put ‘source … thisroot.ch’ at the top of my .tcshrc file just to make sure it wasn’t anything else in my login file that was causing the problem.

thisroot.sh seems to work when I use bash.

Any ideas?

Mac OS 10.6
ROOT 5.27.06 and 5.27.04

Thanks,
Adam

Axel · 2010-12-06T16:39:58.000Z

Hi,

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

Cheers, Axel.

jasondet · 2011-12-09T22:07:42.000Z

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.

Jason

pcanal · 2012-02-08T16:44:48.000Z

Hi Jason,

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.

jasondet · 2012-02-08T21:19:05.000Z

Thank you! -Jason

pdudero · 2015-05-21T00:53:08.000Z

[quote=“pcanal”]Hi Jason,

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?

Thanks,
-Phil D.

pcanal · 2015-05-21T20:56:02.000Z

Hi Phil,

Indeed, this is a problem. Would you be able to propose a solution?

Thanks,
Philippe.

pdudero · 2015-05-22T00:33:06.000Z

Found this solution on the web:

Is it general enough?
-Phil

pcanal · 2015-05-22T01:52:57.000Z

Hi,

Let me know if the thisroot.csh uploaded by this commit http://root.cern.ch/gitweb?p=root.git;a=commitdiff;h=703240b8b238b277384dd61b00738bb5ae7a93bf works for you.

Thanks,
Philippe.

pdudero · 2015-05-27T19:18:00.000Z

Hi, Philippe,

This line looks to have a typo:

if ( "$thisfile" == "" && -e ${thisfile} ) then

“==” should be “!=”, yes?

-Phil

pcanal · 2015-05-27T20:10:44.000Z

Hi Phil,

You are right! I pushed the fixed version to the repository.

Cheers,
Philippe

pdudero · 2015-05-28T00:43:28.000Z

Hi, Philippe,

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”.

Might this work?
-Phil D.

pcanal · 2015-05-28T00:52:03.000Z

Hi Phil,

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?

Thanks,
Philippe.

pdudero · 2015-05-28T16:16:02.000Z

pcanal:

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.

-Phil

pcanal · 2015-05-28T20:56:31.000Z

Hi,

Well, take my attempts to test your changes for example. I don’t have my own root installation to test against.

But then you are not quite testing the ‘real’/‘normal’ use case …

I don’t have my own root installation to test against.

Building ROOT is relatively easy or you could simply copy the installation you do have.

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

I see. It make sense, I agree that user provide information should ‘win’ over guesses. Could you provide a patch implementing what you suggested?

Thanks,
Philippe.

pdudero · 2015-05-29T00:44:43.000Z

Hi, Philippe,

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.

Thanks,
-Phil

pcanal · 2015-05-29T01:03:17.000Z

Hi,

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.

Cheers,
Philippe.

pdudero · 2015-05-29T20:32:06.000Z

Okay,

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

Thanks again,
-Phil D.

pcanal · 2015-05-29T21:28:51.000Z

Hi,

I would copy (cp -rp /afs/cern.ch/sw/…where_root_is /your_writeable_area) and modify it there.

Cheers,
Philippe.