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

From: Axel Naumann <Axel.Naumann_at_cern.ch>
Date: Wed, 9 Mar 2011 14:25:51 +0100


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:25:55 CET

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