Peter Tribble wrote:
On Wed, Oct 7, 2009 at 8:20 AM, Garrett D'Amore <gdam...@sun.com> wrote:
Looking at this stuff, I noticed a few things:
1) we have GNU coreutils (for better or worse) delivering "whoami" into
/usr/bin now. Couldn't /usr/ucb/whoami become a link to that via ../bin/ ?
I guess this would then depend on SUNWgnu-coreutils
How hard is whoami to implement, really? Given that, I'm not keen
on creating a dependency. Heck, why not:
#!/bin/sh
exec /usr/xpg4/bin/id -un
(and why not fix /usr/bin/id to match xpg4?)
Fixing /usr/bin/ vs /usr/xpg4 is a different topic.
But you're right about the "hard to implement". IMO, we should have
just delivered regular "whoami" in /usr/bin, instead of picking up gnu
coreutils. (We never needed a GPL version of it.) But the GNU version
is now there in /usr/bin, and offers identical functionality.
2) /usr/ucb/basename is semantically identical to /usr/xpg4/bin/basename.
So it could be a link to ../xpg4/bin/basename, although that would make it
depend on SUNWxcu4. Right now it doesn't do that. Thoughts?
Why not ditch /usr/bin/basename and make that be identical to the xpg4
version as well (and then link /usr/ucb/basename to /usr/bin/basename).
Is there anything using the non-standard /usr/bin/basename behaviour?
I've never heard of anything using expressions with the suffix in
/usr/bin/basename, but that doesn't mean there isn't stuff doing it.
Changing this would break applications, and actually *removes*
functionality. (The feature /usr/bin/ supports can't easily be replaced
using just /usr/xpg4/bin/basename.)
3) chown differs primarily in that it uses "." instead of ":" to delineate
the group name from the username. It seems like the "standard" (Solaris
version in /usr/bin) could honor *both* : and . fairly easily. (I think
the xpg4 has to remain the way it is to avoid breaking compatibility.) Is
it even possible that a user or group name be constructed that contains "."?
What are the semantics of this?
Well, "." is a valid character in a username. I'm sure I've seen users
have dots in names, and passwd(4) says it's allowed.
Personally, I would ditch /usr/ucb/chown and the owner.group behaviour.
I see no good coming from adding the user.group syntax to /usr/bin/chown
The only small issue I have with that is that /usr/ucb/chown has -h on by
default, which may surprise users who assume /usr/bin/chown behaves
the same way. (I've always wondered why chown -h wasn't the default.)
The -h behavior (thanks for pointing it out, I missed it!) is a nail in
the coffin of this idea. /usr/ucb/chown will have to remain, I'm
afraid. Bummer.
Someone else suggested a workaround for the "." behavior, which was to
look for a username with "." in it first, so we could have worked around
this problem. But the -h behavior requires a different binary anyway....
4) ln -- I don't see how this differs from the stock ln, at least by reading
the manual pages. Can't this just be made a link to either /usr/bin/ln or
/usr/xpg4/bin/ln (whichever semantics are more appropriate?)
Again, why is xpg4 different? The only difference is that /usr/bin/ln
is documented as ignoring -n, but the xpg4 one does so as well.
Dunno, seems like they could be the same to me, as well.
I'm just thinking cleaning up /usr/ucb stuff might be helpful here.
As noted above, it's not just /usr/ucb that needs clearing up. The fact
that we have xpg{4,6} and ucb (and now gnu) in addition to /usr/bin
is a problem; I use /usr/ucb in preference to /usr/bin which shows
how bad some of the /usr/bin commands are. I would love for
Solaris to get to a state where I didn't need to do that. (Casper's
merged ps and the recent ls enhancements are getting us closer.)
Apart from "ps", what else is in /usr/ucb that you need for which the
equivalent in /usr/bin is inadequate? (I think /usr/ucb/install is one
thing I've seen used lots of times by 3rd party software that doesn't
deliver SVR4 packages.... but I'm not proposing doing anything to that.)
I've operated without /usr/ucb in my path fro quite a long time now.
The only thing I've ever missed is ps auxww ... but now Casper has
fixed that. :-)
-- Garrett
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
