On Tue, 9 Mar 2004, Jeremy Enos wrote: > >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?
Sure, it could. It's open source -- http://env-switcher.sf.net/. I'll be happy to accept code contributions. I think you are underestimating how much time it will take. Is it impossible? Certainly not. Am I going to spend the time to do it (including all the testing, re-design, re-implementation, etc.)? Not in the near future. > >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. It's not totally unintitive. Indeed, it even says it right when you run switcher: ----- Attribute successfully set; new attribute setting will be effective for future shells ----- Indeed, the only pseudo-competitor to switcher is softenv. And they have exactly the same kind of command: resoft (just like switcher-reload). Could it be easier? Sure. I've never said that it couldn't be. It's an imperfect world, and I'm offering an imperfect solution. The fact of the matter is that the unix shell was *not* designed to have complex processes change the current environment -- in fact, it's quite contradictory to the "normal" unix model of doing things (every process is its own sandbox). The modules back-end is a total hack (and a very complex one, at that) to be able to do what it does. > >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. I have scratched my itch. Switcher works great, IMHO. I'm not going to fight about this. If you want to fix it, switcher is free and licensed such that you can modify the code to your heart's content. Feel free to do so. And honestly, how many times will people use switcher? Very few times. So why spend a *LOT* of effort in optimizing a relatively uncommon case? Wouldn't we rather have a) a better MPI, or b) OPD mods, or c) database integration, or ....one of a million other things that is pending? This is just not worth it. There are a lot of other, much more important things to do. > 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. Wow. Thanks for those words of praise. :-\ -- {+} Jeff Squyres {+} [EMAIL PROTECTED] {+} http://www.lam-mpi.org/ ------------------------------------------------------- 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
