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

From: Marc Escalier <escalier_at_lal.in2p3.fr>
Date: Wed, 9 Mar 2011 14:55:39 +0100


thanks

you are right

i will do the stuff in pure unix

easier to do

thanks



Axel Naumann a écrit :
> Hi,
>
> I don't understand what you're trying to do (not enough experience with
> Athena, I guess). But it looks like you're better off writing out a bash
> file that you then invoke through Exec().
>
> Cheers, Axel.
>
> Marc Escalier wrote on 03/09/2011 02:26 PM:
>
>> 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
>>
>> ======
>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>
Received on Wed Mar 09 2011 - 14:57:45 CET

This archive was generated by hypermail 2.2.0 : Wed Mar 09 2011 - 17:50:01 CET