Nicolas Williams wrote: > On Tue, Jan 30, 2007 at 03:15:12PM -1000, Joseph Kowalski wrote: > >> Anyway, suffice it to say, we can't even consider mucking with the >> user's setting of PATH. >> Its a non-starter. >> > > Could you clarify something? Just what exactly is a non-starter? > > Mucking with the user's PATH without asking them? (I hope so!) > > Or is any PATH management tool out of the question as well? > > I.e., can we build a GUI tool that can manage users' PATH settings? > > And if we can, can it be invoked on first login, on first login after > update, after patch? > > Because I could see a voluntary PATH management tool as useful. > > Of course, because shell dot files are scripts whose flow control we > could not analyze in such a tool, such a tool would be limited to users > whose shell dot files adhere to some conventions (which the account > skeleton's would). > There is another way to do this.
Actually it could play right into my reply Richard Hamilton's earlier post about moving the 'solaris' environment to /usr/sun. Consider this: The binaries that that post describes are moved to /usr/sun. The Gnu binaries are in /usr/gnu The other environments are in their locations. Other large groups of related binaries could be split out and organized also. Today the 'default' environment is made up of symlinks pulling in the pieces we think the user should see by default today - This would mostly mimic what solaris supplies in /usr/bin today. In the future, /usr/bin (or somewhere else - but then you'd have to change everyone's PATH ;) ) instead becomes many softlinks to a 'wrapper' program that is designed to look up the users' preferences on a per-program (or per-program family) basis - with defaults set as the links were set in the past. A GUI or even CLI is developed to allow the user to pick and choose, the 'flavors', or even 'versions' of the programs (or program families) that they want to use. With everything installed in seperate directories, a tool like this has the flexibility to work. No mucking with the $PATH is needed. No parsing or editing .dotfiles, or concerns about which shell is used. If done correctly perfomance shouldn't be a problem. This is something I've written in the past to manage EDA and CAD tool version selection for groups of developers working on different versions of projects. It's also something I've always would have loved to have seen rolled into the OS itself. If it could be done where it could be configured to allow users to also select and managed 3rd party locally installed software also that would be great. -Kyle
