In article <3C8D143A.17963385@all.com>, Nom de Plume wrote:

> The only step left is sourcing the ora_env.[name] file from within Python in a way
> such that the environment of the parent shell is modified. Anyone have any ideas? I
> have tried:

It is not possible under Unix to modify the environment of your parent process.
You can only modify your own environment and then export that environment to
your children.

--
Grant Edwards grante Yow! I'm DESPONDENT... I at hope there's something visi.com
DEEP-FRIED under this miniature DOMED STADIUM...

In article <pan.2002.03.12.11.14.20.48643.1649@zip.com.au>, Cameron Hutchison wrote:

> What you need to do instead is have your python program print on stdout the name of
> the ora_env file to source. Then you invoke your python script from your shell
> login script like this (bourne style shell assumed):
>
> eval "source ora_env.`get_ora_name`"

Another common method is to have your Python program write the shell commands to
stdout, then execute them with something like

eval `myPythonProgram`

--
Grant Edwards grante Yow! I'm having fun at HITCHHIKING to CINCINNATI visi.com or FAR
ROCKAWAY!!

On Tue, 12 Mar 2002 13:25:57 +1100, Grant Edwards wrote:

> In article <pan.2002.03.12.11.14.20.48643.1649@zip.com.au>, Cameron
> Hutchison wrote:
>
>> What you need to do instead is have your python program print on stdout the name
>> of the ora_env file to source. Then you invoke your python script from your shell
>> login script like this (bourne style shell assumed):
>>
>> eval "source ora_env.`get_ora_name`"
>
> Another common method is to have your Python program write the shell commands to
> stdout, then execute them with something like
>
> eval `myPythonProgram`
>

While that would work fine, I dont think it's a terribly good idea. I think it would
be cleaner to keep the shell syntax in a shell script and avoid having the python
program assume the scripting environment it is returning to.

Cameron Hutchison <camh@zip.com.au> wrote:

> On Tue, 12 Mar 2002 13:25:57 +1100, Grant Edwards wrote:

>> In article <pan.2002.03.12.11.14.20.48643.1649@zip.com.au>, Cameron
>> Hutchison wrote:

>>> What you need to do instead is have your python program print on stdout the name
>>> of the ora_env file to source. Then you invoke your python script from your shell
>>> login script like this (bourne style shell assumed):

>>> eval "source ora_env.`get_ora_name`"

>> Another common method is to have your Python program write the shell commands to
>> stdout, then execute them with something like

>> eval `myPythonProgram`

> While that would work fine, I dont think it's a terribly good idea. I think it
> would be cleaner to keep the shell syntax in a shell script and avoid having the
> python program assume the scripting environment it is returning to.

Having "myPythonProgram" implemented in ANY language (including in ANY shell)
makes exactly the same assumptions: to wit: FOO=BAR assigns shell variables
and either export (Bourne & family) or setenv (csh/tcsh) exports them into
the environment.

*ANY* program or script that is intended to be invoked under eval `....` will
have to make those assumptions.

So the choice of implementation for `foo` is not constrained by the shell
under which it is run (once could offer a command line argument to support
alternative shells: eval `foo -s csh` for example). Since it's not
constrained by this; it should logically be chosen on other criteria, such as
SUITABILITY TO THE JOB AT HAND! (Doh!)

If the OP feels that the parsing and processing that he or she requires is
best done in Python, then Python is just as good at printing "FOO=BAR" and
"export FOO" (Bourne, et al) or "set FOO=BAR" and "setenv FOO" (csh) as any
other language.

Quoth "James T. Dennis" <jadestar@idiom.com>:
| Cameron Hutchison <camh@zip.com.au> wrote:
|> On Tue, 12 Mar 2002 13:25:57 +1100, Grant Edwards wrote:
...
|>> Another common method is to have your Python program write the shell commands to
|>> stdout, then execute them with something like
|
|>> eval `myPythonProgram`
|
|> While that would work fine, I dont think it's a terribly good idea. I think it
|> would be cleaner to keep the shell syntax in a shell script and avoid having the
|> python program assume the scripting environment it is returning to.
|
| Having "myPythonProgram" implemented in ANY language (including in ANY shell)
| makes exactly the same assumptions: to wit: FOO=BAR assigns shell variables
| and either export (Bourne & family) or setenv (csh/tcsh) exports them into
| the environment.
|
| *ANY* program or script that is intended to be invoked under eval `....` will
| have to make those assumptions.

Yes, and that's why it's not really an ideal design! I think that's his point -
don't write your tools to be invoked in an eval statement, if you don't have to.
Or "source", or any solution that requires the tool to know the natural syntax of
its invoker.

How would we write it instead, to avoid this problem? If there's CPU time to spare,
one alternative might be to invoke python separately for each variable, and in that
case python can print out just the value for that variable.

sh: EX1="`exsetup EX1`" export EX1 rc: EX1 = `{exsetup EX1} ... etc.

Donn Cave, donn@drizzle.com