On Tue, 9 Mar 2004, Jeremy Enos wrote:
> >In fact, it would be very difficult to make it change your current > >environment -- there's a bunch of very sitcky technical issues involved. > > Wait... I'm confused. Is this not what switcher-reload does??
Yes. But it's a separate (very small) command. Much easier to do there.
> > > The $(switcher-reload) step should have been executed by the first > > > switcher command above to honor the "principle of least surprise." I'm > > > not aware of any similar "commit" processing at the command line. > > > >It would be really, really hard to do this. > > I don't understand this either. Is it not just doing a switcher-reload > as the last instruction? I thought we had a reason in the past to keep > the two commands separate, but I can't remember it. In the absence of > any reason, I share Dave's thoughts.
No, it is still very very hard to do the full-featured functionality of switcher in a way that can modify your current environment.
Think of it this way -- to modify the current environment, "switcher-reload" can not be a command, because a command runs in a new environment. It's actually an alias. Even more complex, it's an alias of other aliases, each of which do very complex "eval" statements, invoking other, back-end scripts that do the real work. So we've got 3 or 4 levels of abstraction going on here; the real work has to only emit statements (3 of 4 levels deep) that can be interpreted as shell commands to set your PATH, etc.
Making a full-featured switcher command operate 3 or 4 levels deep in terms of abstraction is:
a) very difficult b) very time consuming
Possibly... I'm just trying to understand why. If switcher-reload is already an alias that can execute scripts on the backend, why couldn't a switcher command itself be an alias which does the same thing, but ran an extra script which was the actual switcher command?
c) totally different than what we have already established
Yet not totally different from what's intuitive, as Dave pointed out. I'd rather strive to match what's intuitive rather than a previous version.
d) what the "module" command already does
From what I've seen in user needs, using the module command w/o also needing a static change is a corner case. The vast majority would benefit from having a single command which performs the most common need: static and current change. But instead, it essentially makes them perform two steps for something that *intuitively* could be one step.
Please RTFM.
I merely pass on to you what I get back from the user experience. I cannot (will not) pass this back to them unless I feel they're being unreasonable. Besides that, IF we can make something easier for the user that makes sense to them, we should be taking that route rather than the RTFM approach. That approach is contradictory to all our effort put into OSCAR in general.
I say all this knowing that you may have a perfectly kosher explanation of why it's impossible or too much effort for the benefit. As I mentioned above, I'd just like to understand why.
Jeremy
------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Oscar-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/oscar-devel
