os.environ and os.path.chdir

[Yun Mao]

Hi,
How to make changes to os.environ and os.path.chdir still effective after
I run the script? Currently, the changes are only good within my script. I
would like the shell who called python myprog.py also gets the change..
Thank you!

Yun

 

[Geoff Gerrietts]

Quoting Yun Mao ([email protected]):

Hi,
How to make changes to os.environ and os.path.chdir still effective after
I run the script? Currently, the changes are only good within my script. I
would like the shell who called python myprog.py also gets the change..
Thank you!

To the best of my knowledge, this can't be done. Depending on the
specific application, you might have several workarounds.

One is to exit into a new shell, using os.execve instead of sys.exit.
That creates "nested" shells, unless the user exec's your program
also.

Another is to exit by printing a list of commands, and expect that the
user will run your program like "eval `myprog.py`" to execute those
commands.

As far as I know, though, there's no way to actually hijack the user's
shell process. The user needs to explicitly give you that control.

--G.

 

[Peter Hansen]

How to make changes to os.environ and os.path.chdir still effective after
I run the script? Currently, the changes are only good within my script. I
would like the shell who called python myprog.py also gets the change..

Is there some Python programming course where all you guys are
coming from lately? This question seems very popular this week.

As John Roth just replied to one of your potential classmates ,
"Look at the thread "Setting Environment Variables" that started
yesterday in the early morning." ... and note that the comments
about environment variables apply equally to the current directory,
as both are properties of the calling shell and can be changed only
by scripts run by that shell.

-Peter

 

[Dennis Lee Bieber]

Geoff Gerrietts fed this fish to the penguins on Friday 19 September
2003 04:30 pm:

As far as I know, though, there's no way to actually hijack the user's
shell process. The user needs to explicitly give you that control.

A fully integrated REXX system could do it... This requires the
"shell" to process IBM's default "queue". The REXX program would write
the "CD ..." command to the QUEUE and, on exit, the command interpreter
would read/process whatever is in the queue before reading keyboard
input.

I don't believe the Linux OREXX is quite that integrated.

--

 

[Thomas Bellman]

Quoting Yun Mao ([email protected]):

To the best of my knowledge, this can't be done. [...]
As far as I know, though, there's no way to actually hijack the user's
shell process. The user needs to explicitly give you that control.

Actually, there are a couple of ways to do it, at least under
Unix. However, they have their problems...

One way is to stuff characters into the terminals input buffer
using the TIOCSTI ioctl. Like this:

import fcntl, termios
for c in "cd /usr/lib\n":
fcntl.ioctl(1, termios.TIOCSTI, c)

It only works if it is being run interctively, under a tty,
though. If you have a shell script running the above program,
the shell script won't see the command, and thus won't change
directory. It will be the original shell that gets the command.
And if you're not on a tty, it doesn't work at all.

Also, the command you stuff into the terminal can get mixed up
with normal type-ahead typed by the user, leaving some garbled
command for the shell to read.

So, it's not very reliable.


Another way is to attach a debugger to the parent process, and
force it to do the chdir() system call, or poke around in its
memory to change the environment variables. Like this:

import os
gdb = os.popen('gdb $SHELL %d' % (os.getppid(),), 'w')
gdb.write('call chdir("/usr/lib")\n')
gdb.write('detach\n')
gdb.write('quit\n')
gdb.close()

Untested code, but you probably get the idea.

Changing the environment variables of the parent is a bit
trickier. You need to know the memory layout of the parent,
so you can poke the correct bytes. You might be able to locate
the variable 'environ' and follow it, but there is no guarantee
it is still pointing to anything useful.


However, I would recommend *against* both of these methods.
Don't try any of this stuff youselves, kids; always get a parent
to supervise this kind of experiments!