James Carlson <james.d.carlson at Sun.COM> wrote:
> Stephen Hahn writes:
> > * James Carlson <james.d.carlson at Sun.COM> [2007-01-30 12:03]:
> > > Stephen Hahn writes:
> > > > (In John's example, star poses no conflict
> > >
> > > Actually, it does. I don't necessarily agree with him, but Joerg has
> > > good reason to want 'star' to be /usr/bin/tar.
> >
> > In the interests of having a finite discussion, I must point out that
> > this case, /usr/gnu, has nothing to do with implementation
> > replacements like the example above. It proposes no replacements and
> > in no way modifies the responsibilities of subsequent projects that
> > wish to replace any individual implementation.
>
> I think you're missing the point I was trying to make, because I
> didn't intend to refer _only_ to replacement. One alternative to
> blasting star atop /usr/bin/tar is to have a /usr/schilly universe,
> along with the /usr/gnu, /usr/ucb, and other universes.
> (Multiverses?)
>
> In the 'schilly' universe, unadorned 'tar' is star.
I don't know what you understand by "unadorned 'tar'"...
Star behaves differently when called "tar".
If you call star "star", you get a CLI that is close to the POSIX
CLI standard for commands, if you call it "tar", you get a SUSv2
compliant tar CLI.
Star has been developped with a different background than GNU tar.
GNU tar did not claim to be compliant to the standard but to be the
"tar standard" on Linux.
Star gives you a SUSv2 compliant tar CLI but enciourages you to use the
extended CLI that comes with the name "star".
J?rg
--
EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
js at cs.tu-berlin.de (uni)
schilling at fokus.fraunhofer.de (work) Blog:
http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
