Hi,
On 05/10/07 07:07, David Lloyd wrote:
[snip]
2. Rethinking the way a shell is used or what a shell offers for
different uses of an operating system
[in some instances, having to guarantee you've got:
/usr/openwin/bin/dtterm instead of /usr/bin/dtterm
...is important.
in other instances, it's a total PITA to have to remember where
everything is AND to have to type its full path OR to have to change
the default PATH _and_ then have to hope nothing else breaks]
[snip]
Agreed. I'd like to see some innovation around the dumb old shell pathing
mechanism. It's too coarse now - if I prioritize say /opt/sfw/bin for one
thing I get that things from there in preference to everything that
follows it in the path. I can use shell aliasing or a forest of symlinks
from a private bin directory, but there should not be a need to reinvent
such a personalisation mechanims each time.
I'd prefer to use a shell where no PATH env variable exists. Instead
there is simply some default mechanism that exposes all the
common binary repositories to me in some default order, perhaps
influenced by some sysadmin-chosen input such as "gnu behaviour
system-wide". I should then also be able, should I wish/care,
to express a preference for flavours of particular utilities
for use in my interactive shell environments - eg selecting
whether gnu awk, nawk or awk is used when I use an unqualified
'awk' on the cmdline.
Designing such a system for customising the cmdline experience is
not difficult. I think the problem comes in scripting environments -
when a user with a customised preferences runs a script do those
preferences extend to the script. Many scripts will break when
unexpected utility flavours are selected. Perhaps some additional
mechanism for associating an environment preference for each script
would be an suitable approach: tag a script as "old school Solaris",
"from <distro> linux" etc.
Just a thought.
Gavin
_______________________________________________
opensolaris-discuss mailing list
[email protected]
