| 1 |
2009/7/23 Nirbheek Chauhan <nirbheek@g.o>: |
| 2 |
> 2009/7/23 Sérgio Almeida <mephx.x@×××××.com>: |
| 3 |
>> A child process cannot (or shouldn't be able to) change parent's process |
| 4 |
>> environment. |
| 5 |
>> |
| 6 |
>> uprofile will need to change env var's on-the-fly. For instance tag $PS1 |
| 7 |
>> with the current profile in use |
| 8 |
>> |
| 9 |
> |
| 10 |
> I don't understand what use this feature has. Won't the "current |
| 11 |
> profile" be persistent across shells? If so, won't PS1 not be |
| 12 |
> persistent if you change in on-the-fly? If you don't intend to keep it |
| 13 |
> persistent, what's the use? (Actually, I don't see the use of having |
| 14 |
> it at all) |
| 15 |
|
| 16 |
I think the point he is making is that when you update the environment |
| 17 |
variable, you want it to start reflecting in the current shell |
| 18 |
immediately. Correct me if I'm wrong. |
| 19 |
|
| 20 |
If this is the case, spawning a new shell might not be an option, |
| 21 |
since you will lose the shell's history (you'll even need to do some |
| 22 |
work to make sure you spawn the same shell (bash/csh/zsh) as the user |
| 23 |
is currently using. And there's going to be an element of surprise if |
| 24 |
multiple calls to uselect end up meaning that the user needs to use |
| 25 |
Ctrl-D/logout/exit several times to end the current session. |
| 26 |
|
| 27 |
IMO, it is cleaner to just print a message telling the user to source |
| 28 |
/etc/profile as eselect does currently. |
| 29 |
|
| 30 |
Keep up the good work. |
| 31 |
-- |
| 32 |
Arun Raghavan |
| 33 |
http://arunraghavan.net/ |
| 34 |
(Ford_Prefect | Gentoo) & (arunsr | GNOME) |
Archives