Tom Anderson twic at urchin.earth.li
Wed Dec 21 01:34:37 CET 2005

On Tue, 20 Dec 2005, Steve Holden wrote:

> Mike Meyer wrote:
>> Terry Hancock <hancock at anansispaceworks.com> writes:
>>> On Tue, 20 Dec 2005 05:35:48 -0000
>>> Grant Edwards <grante at visi.com> wrote:
>>>> On 2005-12-20, dpugmire at gmail.com <dpugmire at gmail.com>
>>>> wrote:
>>>>> I have csh script that calls a bunch of python programs and I'd like 
>>>>> to use env variables as kind of a global variable that I can pass 
>>>>> around to the pythong scripts.
>>>> You can't change the environment of the parent process.
>>> There is an evil trick, however:
>>> Instead of setting the environment directly, have the python program 
>>> return csh code to alter the environment the way you want, then call 
>>> the python code by "sourcing" its output:
>>> source `my_script.py`
>> Does this actually work? It looks to me like you need two levels:
>> my_script.py creates a file, then outputs the name of the file, as the
>> csh source command reads commands from the file named as an argument.
>> To be able to output the commands directly, you'd need to use the eval
>> command, not the source command.
> I suspect the trick that Terry was thinking of was eval, not source. You are 
> correct in saying he'd need to create a file to source.

True. The downside of eval is that it doesn't (well, in bash, anyway) 
handle line breaks properly (for some value of 'properly') - it seems to 
treat them as linear whitespace, not line ends. I was about to suggest:

source <(my_script.py)

As a way to use source to run the script's output, but that seems not to 
work. I think <() might be a bashism anyway.


Hit to death in the future head

More information about the Python-list mailing list