Nicolas Williams wrote: > On Thu, Jan 25, 2007 at 05:16:34PM +0000, Pete Bentley wrote: > >>> A second reason to not do this: >>> [...] >>> It's bad practice in general to begin have an NFS directory too early in >>> your $PATH. >>> >> NFS or no, the more names you dump into /usr/bin (which is expected to >> be early in people's PATH), the more likely you are to mask some local >> application (or locally tailored version of an application) in a >> directory further down the PATH which I think violates the Principle of >> Least Astonishment. >> > > That's an argument for closing off /usr/bin. Everything should go into > a /usr/pkg/*/bin or /opt/*/bin or whatever, and every user is > responsible for maintaining a very long PATH or a lynk farm. > > > Engineering is about trade-offs, and that's not a very good one. Making > 90% of users happy and telling the other 10% to manage their PATHs is a > very reasonable engineering decision, and you can see serendipitous > discovery as just that. > > I agree it's about trade-offs. And if it were possible to work around this by 'managing' my PATH I'd just do it.
But this change is effectively 'trading off' the users ability to do what I'm describing by managing their PATH. There is no other PATH that can be used to do this. > As for things like the multiplicity of versions of things like Perl or > Apache, this is the case regardless of whether any one version of those > appears in /usr/bin. When you know you need a specific version of Perl > then use that in your scripts, not the default version. > > If it were only calling things from scripts that'd be fine. (I do hard code #1 references and other calls to exectuables in my scripts already.) But when it comes to running things from the command line there's no other choice - well users could create aliases for every command... You think maintiaining PATHs in dot files is work, try maintaining aliases for ever executable that you want to avoid getting from /usr/bin. -Kyle > Nico >
