Re: Useful Features?
Manage your shell environment variables and aliases
Brought to you by:
leomania,
xdelaruelle
From: Dave W. <dwi...@Ba...> - 1996-10-16 21:37:37
|
Ian, Let me know if you get any helpful responses. With respect to features, I think it might be useful to be able to add a tool setup to the middle of a path (ahead of current applications, but behind normal environment bins). The only way to do this now (in Modules) is unload all applications, and reload them in the correct order. I've toyed with the idea of having multiple sub-paths that get fused together when a tool/application is setup. For example: $ENVIRONMENT_PATH = /bin:/usr/ucb:/usr/bin/:. $APPLICATION_PATH = /xyz/synopsys/3.4b:/xyz/cadence/3.0 $PATH = ${ENVIRONMENT_PATH}:${APPLICATION_PATH} A tool setup for an application would append or prepend to the APPLICATION_PATH, but these bins could never (?) eclipse the ENVIRONMENT_PATH bins. This takes a little more work to setup and could probably be implemented in Modules or "the package system". What are you thoughts on this? An implementation for this might include another env var to determine how the $PATH gets built. For example: $PATH_RECIPE = ENVIRONMENT_PATH:APPLICATION_PATH As a step towards an implementation of this, all modulefiles I have created source a common Tcl file at the end of loading. This is where I planned to do PATH build if that ever proved useful. Would something like this add much to the whole system? for users? for applications admins? for Network Eng? Is there a better way to accomplish the same thing? If you want to stop by some time we could discuss this over air hockey. One last thing, let me know if you end up modifying Modules to add a runtime (append/prepend) switch and change the conflict mechanism to a lock mechanism. I think it might be useful to also add a generic parameter passing mechanism so that other misc args could be passed to modulefiles. This might facilitate future extensions. Thoughts? Dave |