Joerg Schilling writes: > > Despite having a 4 kiloline man page, star doesn't support the same > > options as Solaris tar. It's not a drop-in compatible replacement, > > and the interfaces in Solaris tar are listed as "Stable," meaning that > > we promise not to break them until the next Major release (and perhaps > > not then, if we can avoid it). > > Please try to inform yourself before writing obviously wrong claims.
Please try to avoid ad-hominem attacks. They don't help you advance any of your claims. > If you today compare star's "tar" CLI interface with Sun's tar CLI interface, > you will find only 3 Sun tar options that are not supported by star. Two of > them (-@ and -T) are creating deprecated archive format extensions and the > third (-n) could just be ignored. Star on the other side implements 130 basic And, hence, it's not compatible. -@ and -T are documented and stable parts of tar(1) on Solaris. I understand that you don't like them, but they're not going away without substantial justification and a transition plan. (Merely breaking existing users is not a "plan.") > options that are missing from Sun tar (not counting the find(1) CLI that is > integrated into star). The issue isn't with added features. > If you like to continue a useful discussion, please inform yourself about > the current reality and don't forget that I did never ask to _replace_ Sun's > tar by star _today_ but in the future. It would help a lot if you did just try Your plan was to move /usr/bin/tar to /usr/bin/otar, and link /usr/bin/tar to /usr/bin/star, correct? That plan involves causing at least those two committed features (extended attributes and TX support) to disappear. You didn't specify what a transition plan would look like or how users would cope with the change -- other than having their cron jobs suddenly and mysteriously stop working. > to use star for a while and to understand how it works, what features it has > and why you would miss star on your daily work after you managed to use the > features from star. Honestly, having Solaris tar and GNU tar is plenty for me. I haven't missed much of anything from either, and when I need to do something fancy, I usually use pax. Yes, I have star installed on a couple of my systems. I rarely have a need for it, though. > suntar > tar A nearly comlete implementation of the Sun tar CLI and feature list. "Nearly complete?" In any event, you're right on this one part. I've never tried to use star in this mode, because it's never installed as "tar" on any of my systems. > > This means _at least_ an EOF for tar itself. Whether it's an > > I am not sure what you like to say here, this looks a bit confused - sorry. I don't think so. Making incompatible changes to or outright removing committed features is serious business. In architectural terms, we need to go through an "End Of Feature" process in order to do that. An introduction to the topic is available here: http://www.opensolaris.org/os/community/arc/policies/obsolete-eof/ > It seems that you did never read recent related primary information from the > POSIX standard or that you missunderstand the POSIX CLI guidelines. That's the only obvious explanation. > - POSIX does not forbid long options, but POSIX will (currently) > not add long options to programs that are inside the POSIX > specification. Long options on Solaris, when present at all, quite intentionally are expected to follow the GNU model, which means "--option" and not "-option", in order to avoid direct conflicts with the getopt *style* of option processing. See requirement #15 in CLIP (PSARC 1999/645). More importantly, we very much do want to have Solaris components (as much as possible) to resemble each other. It's an ease-of-use issue. Thus, having some things sprouting "-option" and others with "--option" is a system-wide self-consistency problem. That was the point of the CLIP specification. But I'll decline to speculate on whether anyone else has read that. :-/ > - "tar", "ar" and "dd" do not follow the POSIX CLI spec and do > not need to. Quite correct; they proudly don't follow the spec. It's much less clear -- in the case of tar in particular -- whether they need to have new options that deliberately fall outside that spec. > - If "star" is called under the name "tar" or "suntar", it parses > the command line in a way that is fully compliant to SUSv2. > If you have problems with tar implementations that do not follow > this standard, please remove GNU tar from the Sun Solaris > distribution. /usr/bin/tar isn't GNU tar, and (at least for Solaris) never will be, so I have no problem with it. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
