Re: gSystem->Exec() : memory of variables

Marc,

On Wed, 9 Mar 2011 14:26:17 +0100, Marc Escalier <escalier_at_lal.in2p3.fr> wrote:
> Hi,
>
> thanks to the help of many of you, i continue with definition of python,
> obtaining this :
>
> //begin definition of python :
> gSystem->Setenv("PYTHON_VER","2.6");
> gSystem->Setenv("PYTHON_DIR","'/usr/local/python/python-${PYTHON_VER}'");
> gSystem->Setenv("export PATH","'${PYTHON_DIR}/bin:${PATH}'");
> gSystem->Setenv("export CFLAGS","'-L /usr/local/python/python-2.6/lib'");
> gSystem->Setenv("LD_LIBRARY_PATH","'$PYTHON_DIR/lib:$LD_LIBRARY_PATH'");
>
> // gSystem->Exec("python"); //this commands works
> //end definition of python
>
> //gSystem->Setenv("amiGetDatasetEVNTInfo","'python
> /afs/cern.ch/atlas/software/releases/16.6.2/AtlasCore/16.6.2/Database/Bookkeeping/AMIClients/pyAMI/python/amiGetDatasetEVNTInfo.py'");
> gSystem->Exec("asetup 16.6.2");
> gSystem->Setenv("amiGetDatasetEVNTInfo","python
> /afs/cern.ch/atlas/software/releases/16.6.2/AtlasCore/16.6.2/Database/Bookkeeping/AMIClients/pyAMI/python/amiGetDatasetEVNTInfo.py");
> gSystem->Exec("`echo $amiGetDatasetEVNTInfo`");
>
> but the amiGetDatasetEVNTInfo crashes only because one needs to define
> asetup 16.6.2, which i can't do *inside* root

so you want to programmatically setup an Athena environment from within CINT ? it's already cumbersome enough from the shell with all the CMT voodoo stuff... even if the new 'asetup' somewhat eased a bit the pain, it's still no 'day at the ballpark' either...

believe me, Wim (and I) did it from within python and there it was already a pain to manage a subshell programmatically.

you are probably better off writing the shell script which setups athena and defines the alias rather than re-inventing the CMT squared wheel From CINT.

-s

>
> ======
> Axel Naumann a écrit :
> > Hi Marc,
> >
> > That's not what Georg wrote - note the '$' sign.
> >
> > Anyway, you could probably assign it to a C++ variable and use that,
> > instead of an environment variable.
> >
> > Cheers, Axel.
> >
> >
> > Marc Escalier wrote on 03/09/2011 01:51 PM:
> >
> >> thanks, i try to do an alias within root :
> >> ==>
> >>
> >> gSystem->Setenv("amiGetDatasetEVNTInfo","'python
> >> /afs/cern.ch/atlas/software/releases/16.6.2/AtlasCore/16.6.2/Database/Bookkeeping/AMIClients/pyAMI/python/amiGetDatasetEVNTInfo.py'");
> >>
> >> gSystem->Exec("`amiGetDatasetEVNTInfo`");
> >>
> >> gives :
> >> sh: amiGetDatasetEVNTInfo: command not found
> >>
> >> while in unix :
> >> ccali16% alias amiGetDatasetEVNTInfo='python
> >> /afs/cern.ch/atlas/software/releases/16.6.2/AtlasCore/16.6.2/Database/Bookkeeping/AMIClients/pyAMI/python/amiGetDatasetEVNTInfo.py'
> >>
> >> ccali16% amiGetDatasetEVNTInfo
> >>
> >> does something
> >>
> >> =============================
> >> Georg Troska a écrit :
> >>
> >>> Hi,
> >>>
> >>> a variable is not an alias.
> >>> doing in bash
> >>>
> >>> # A="xclock"
> >>> # echo $A
> >>>
> >>> will not work either.
> >>> Probably not the best way, but
> >>>
> >>> root[] # gSystem->SetEnv("A","xclock")
> >>> root[] # gSystem->Exec("`echo $A`")
> >>>
> >>> will work.
> >>> Georg
> >>>
> >>>
> >>>
> >>>
> >>>> but the folllowing doesn't "work":
> >>>>
> >>>> root [1] gSystem->Setenv("amiGetDatasetEVNTInfo","'python
> >>>> /afs/cern.ch/atlas/software/releases/16.6.2/AtlasCore/16.6.2/Database/Bookkeeping/AMIClients/pyAMI/python/amiGetDatasetEVNTInfo.py'")
> >>>>
> >>>> root [2] gSystem->Exec("amiGetDatasetEVNTInfo")
> >>>> sh: amiGetDatasetEVNTInfo: command not found
> >>>>
> >>>> while in unix :
> >>>> alias amiGetDatasetEVNTInfo='python
> >>>> /afs/cern.ch/atlas/software/releases/16.6.2/AtlasCore/16.6.2/Database/Bookkeeping/AMIClients/pyAMI/python/amiGetDatasetEVNTInfo.py
> >>>>
> >>>> amiGetDatasetENVInfo
> >>>> "works"
> >>>>
> >>>> would you have a hint ?
> >>>>
> >>>> ===============
> >>>>
> >>>> Dario Berzano a écrit :
> >>>>
> >>>>
> >>>>> Hello,
> >>>>>
> >>>>> each gSystem->Exec(), just like the standard C system() function,
> >>>>> opens a new shell ("man system" says /bin/sh) with a brand new
> >>>>> environment.
> >>>>>
> >>>>> But in ROOT you can set environment variables that are seen by
> >>>>> subshells launched either via gSystem->Exec() or
> >>>>> gSystem->OpenPipe()/GetFromPipe(): for instance you can play with
> >>>>> the following code:
> >>>>>
> >>>>> // The environment variable COUNTER is set to 0
> >>>>> gSystem->Setenv("COUNTER", "0");
> >>>>>
> >>>>> // COUNTER is incremented in subshells and its value is set to ROOT's
> >>>>> // (*not* shell's) environment
> >>>>> for (Int_t i=0; i<100; i++) {
> >>>>> gSystem->Setenv("COUNTER", gSystem->GetFromPipe("expr $COUNTER +
> >>>>> 1"));
> >>>>> }
> >>>>>
> >>>>> // A subshell is spawned to echo the value of envvar COUNTER
> >>>>> gSystem->Exec("echo Variable COUNTER has value $COUNTER");
> >>>>>
> >>>>> Please note that opening/closing 100 subshells just to increment a
> >>>>> variable's value 100 times isn't very performance-friendly...
> >>>>>
> >>>>> Cheers,
> >>>>> --
> >>>>> : Dario Berzano
> >>>>> : INFN & Università - Torino, Italy
> >>>>> : Wiki: http://newton.ph.unito.it/~berzano
> >>>>> : GPG: http://newton.ph.unito.it/~berzano/gpg
> >>>>> : Mobile: +39 348 72 22 520
> >>>>>
> >>>>>
> >>>>> Le 9 mars 2011 à 11:53, Marc Escalier a écrit :
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>> Hello,
> >>>>>>
> >>>>>> in root, there are the methods TSystem::Exec() and
> >>>>>> TSystem::GetFromPipe which have the same behaviour for the
> >>>>>> following issue :
> >>>>>>
> >>>>>> if one does in unix :
> >>>>>> a=3
> >>>>>> echo $a
> >>>>>> it works
> >>>>>>
> >>>>>> but in root :
> >>>>>> if ones does :
> >>>>>> gSystem->Exec("b=3);
> >>>>>> gSystem->Exec("echo $b")
> >>>>>> it will "forget" the b
> >>>>>>
> >>>>>> only this works :
> >>>>>> gSystem->Exec("c=3;echo $c")
> >>>>>>
> >>>>>> ==>
> >>>>>> is there a way to have the memory of the variables for several
> >>>>>> gSystem->Exec() commands ?
> >>>>>> (in order to do some instructions ones, and some others inside a loop)
> >>>>>>
> >>>>>> (i tried also with export, but it doesn't help)
> >>>>>>
> >>>>>> thanks
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >>
>

-- 
#########################################
# Dr. Sebastien Binet
# Laboratoire de l'Accelerateur Lineaire
# Universite Paris-Sud XI
# Batiment 200
# 91898 Orsay
#########################################






application/pgp-signature attachment: stored