kar1107@gmail.com
1/13/2008 12:50:00 AM
On Jan 12, 6:19 am, Svenn Are Bjerkem <svenn.bjer...@googlemail.com>
wrote:
> On Jan 9, 9:18 pm, Zentrader <zentrad...@gmail.com> wrote:
>
> > On Jan 9, 5:56 am, Svenn Are Bjerkem <svenn.bjer...@googlemail.com>
> > wrote:
>
> > >I have been looking for a way to execute this command
> > > as a part of a script, but it seems that the changes are only valid in
> > > the context of the script and when the script exits, the current shell
> > > still have the original "users" group setting.
>
> > I don't think you would want it any other way. Would you want a user
> > to be able to change the group and have it remain permanently? Who's
> > going to remember whether they were last in "A" or "B", and it opens
> > up oportunities for the practical joker when you go to the restroom
> > and leave the terminal on. Put the "change the group" code into a
> > separate function in a separate file (with only you as the owner) and
> > call it whenever you want to change groups.
>
> I am trying to create a script that make it easy for users in a design
> team to create files that belong to the same group, but retain the
> users uid. In order to make it visible that the user is creating files
> with a different gid, the script will change the prompt to indicate
> so. In a tcl solution I have now, the users home is changed to the
> design area as some tools are reading and writing setup files into
> $HOME. I have not found a way to change the gid in tcl so I turned to
> python in hope that this scripting language could do so.
>
> The tcl solution spawns a new tcsh after setting several environment
> variables and works quite well except for not being able to change
> gid. And it is also a wish from my side to port this script to python.
>
> Is your suggestion to put "newgrp design" into a new file and then
> exec this file in my python script? What happens to the group id of
> the shell that called the python script in this case? I would try to
> avoid spawning a new tcsh as this make execution of tools on a remote
> computer difficult as the handover of command line arguments does not
> seem to be handed over to the newly spawned shell. I may be
> understanding something wrongly here.
When you fork a process in unix/linux, the child inherits all of
parents settings; *but* any future changes that is made in child
process will not get reflected in the parent.
So there is no way you can fire a process and some how get its setting
back to the invoking shell (which could be anything btw, say bash/tcsh/
csh).
Thus what you really want is start a wrapper python script, say
setup_design.py
In setup_design.py, call necessary os routines like setegid(egid);
this will update the process settings of the process running
setup_design.py.
At the end of setup_design.py, do an exec call[1] to fire the user's
shell (note that even if you use popen or other ways of forking a new
process, things will work just fine) Whatever changes you made to the
process environment will get propagated to the new shell. User must
explicitly finish the new shell (say typing 'exit' on shell prompt)
Karthik
[1]. e.g.
import os
os.execvp(cmd_run[0], cmd_run) # cmd_run is probably ['/bin/bash']
>
> --
> Svenn