On Thu, 2009-07-23 at 13:17 +0530, Arun Raghavan wrote:
> 2009/7/23 Nirbheek Chauhan <nirbheek@g.o>:
> > 2009/7/23 Sérgio Almeida <mephx.x@...>:
> >> A child process cannot (or shouldn't be able to) change parent's process
> >> environment.
> >>
> >> uprofile will need to change env var's on-the-fly. For instance tag $PS1
> >> with the current profile in use
> >>
> >
> > I don't understand what use this feature has. Won't the "current
> > profile" be persistent across shells? If so, won't PS1 not be
> > persistent if you change in on-the-fly? If you don't intend to keep it
> > persistent, what's the use? (Actually, I don't see the use of having
> > it at all)
> 
> I think the point he is making is that when you update the environment
> variable, you want it to start reflecting in the current shell
> immediately. Correct me if I'm wrong.
> 

That's correct and incorrect. Let's distinguish YOUR profile from A
profile. As I explained to Nirbheek folders can have profiles and these
we want to be able to take effect immediately. 

> If this is the case, spawning a new shell might not be an option,
> since you will lose the shell's history (you'll even need to do some
> work to make sure you spawn the same shell (bash/csh/zsh) as the user
> is currently using. And there's going to be an element of surprise if
> multiple calls to uselect end up meaning that the user needs to use
> Ctrl-D/logout/exit several times to end the current session.
> 

I agree, just have in mind that it won't be uselect that needs to change
these on the fly. Uselect will notify to source your profile as eselect
does.

For uprofile we can always wrap it under a sh script and source it's
stdout after it ran. <- solution?

> IMO, it is cleaner to just print a message telling the user to source
> /etc/profile as eselect does currently.
> 
> Keep up the good work.

Thanks. Cheers,
Sérgio
-- 
Sérgio Almeida - mephx.x@...
mephx @ freenode