Darren J Moffat [EMAIL PROTECTED] wrote:
On Thu, 2005-12-01 at 11:30, Joerg Schilling wrote:
If you take this seriously, then ZFS could not have been allowed to be
released
the way it has been, because SVN_27 introduces incompatible changes in the
ACL
interface that would have to be
[EMAIL PROTECTED] wrote:
It's kinda hard to mistype gnome-short-command-names-are-so-not-practical
as zpool destroy ... too.
You may be right with those short commands, but how about the longer
commands with 2 or 3 chars that are similar to frequently typed program names?
In any way: I don't
On Thu, 2005-12-01 at 11:30, Joerg Schilling wrote:
If you take this seriously, then ZFS could not have been allowed to be
released
the way it has been, because SVN_27 introduces incompatible changes in the ACL
interface that would have to be addressed before note that these
On Tue, 29 Nov 2005, Bryan Cantrill wrote:
but we know from painful experience that acts of cowardice like
/usr/proc/bin create more problems than they solve.
Curious, what problems other than $PATH would those be?
The shell PATH issues at least can easily be dealt with with some
Alan DuBoff [EMAIL PROTECTED] wrote:
As other tars just do not have enough features, I guess that you call
star anyway. But for scripts it is of course needed to have a conforming
tar in the PATH. Conforming means that the program called under the name
tar must not cause unexpected
On Thursday 01 December 2005 03:30 am, Joerg Schilling wrote:
In former times, it was usual to (by intention) have a limited PATH
for root in order to reduce provlems by miss-typed commands and similar.
Let's try to forget about the past, and let's try to look towards the future.
We also had
On Thursday 01 December 2005 05:33 am, Joerg Schilling wrote:
First, POSIX currently does not longer contain tar.
And if you install star as /usr/bin/tar, you get 99.99% compatibility with
Sun's tar and 100% compatibility with the latest POSIX that did include
tar.
That's fine. wether the
PJ == Paul Jakma [EMAIL PROTECTED] writes:
PJ On Tue, 29 Nov 2005, Bryan Cantrill wrote:
but we know from painful experience that acts of cowardice like
/usr/proc/bin create more problems than they solve.
PJ Curious, what problems other than $PATH would those be?
Nobody
On Thu, 1 Dec 2005, Matthew Simmons wrote:
Nobody finds them, because they're out of the way.
It's also an annoyance for administrators, because they have to add
yet another directory to their PATH.
Much better to put the new feature right in their path, so to speak,
than to make them have
PJ == Paul Jakma [EMAIL PROTECTED] writes:
PJ On Thu, 1 Dec 2005, Matthew Simmons wrote:
Nobody finds them, because they're out of the way.
It's also an annoyance for administrators, because they have to add yet
another directory to their PATH.
Much better to
Bart Smaalders [EMAIL PROTECTED] wrote:
My reason for preferring /usr/bin unless there's a name conflict is
simply this : if users cannot readily find a command, they implicitly
assume it isn't available. There is basically no benefit obtained from
hiding commands in strange places around
On Wed, 2005-11-30 at 13:41, Joerg Schilling wrote:
Bart Smaalders [EMAIL PROTECTED] wrote:
My reason for preferring /usr/bin unless there's a name conflict is
simply this : if users cannot readily find a command, they implicitly
assume it isn't available. There is basically no benefit
On Wed, 2005-11-30 at 02:08, Alan Coopersmith wrote:
Bryan Cantrill wrote:
Suffice it to say that we have learned the hard way: put it in /usr/bin
unless there's a conflict that prevents it.
Though I still get complaints about GNOME being in /usr/bin, since it makes
it harder to
On Wednesday 30 November 2005 05:41 am, Joerg Schilling wrote:
The reason why I still have objections against this idea is that
you may like to create a PATH that includes less binaries and thus seems to
me less dabgerous for administrators.
This type of situation is an exception, for
Paul Durrant [EMAIL PROTECTED] wrote:
Initial Proposal
* GNU commands that don't collide with current /usr/bin namespace -
place these in /usr/bin.
* GNU commands that do collide with commands already in /usr/bin -
place these in /usr/gnu/bin, following the convention we
Nikhil wrote:
I believe all of them putting under /usr/gnu/{lib,bin,include} whatever
specific to gnu under /usr/gnu as prefix directory would be better.
Do you have a reason?
My reason for preferring /usr/bin unless there's a name conflict is
simply this : if users cannot readily find a
On Tue, Nov 29, 2005 at 11:22:52AM -0800, Bart Smaalders wrote:
Nikhil wrote:
I believe all of them putting under /usr/gnu/{lib,bin,include} whatever
specific to gnu under /usr/gnu as prefix directory would be better.
Do you have a reason?
My reason for preferring /usr/bin unless
Bryan Cantrill wrote:
Suffice it to say that we have learned the hard way: put it in /usr/bin
unless there's a conflict that prevents it.
Though I still get complaints about GNOME being in /usr/bin, since it makes
it harder to install another version and without breaking all the existing
On Tue, 2005-11-29 at 18:08 -0800, Alan Coopersmith wrote:
Bryan Cantrill wrote:
Suffice it to say that we have learned the hard way: put it in /usr/bin
unless there's a conflict that prevents it.
Though I still get complaints about GNOME being in /usr/bin, since it makes
it harder to
Alan Coopersmith wrote:
Bryan Cantrill wrote:
Suffice it to say that we have learned the hard way: put it in /usr/bin
unless there's a conflict that prevents it.
Though I still get complaints about GNOME being in /usr/bin, since it
makes
it harder to install another version and without
I believe all of them putting under /usr/gnu/{lib,bin,include}
whatever specific to gnu under /usr/gnu as prefix directory would
be better.On 11/23/05, Eric Boutilier [EMAIL PROTECTED] wrote:
[ Followups: _Please_ post followups only to the GNU-Solaris community list:[EMAIL PROTECTED]
21 matches
Mail list logo
