James Carlson <[EMAIL PROTECTED]> wrote:
> Joerg Schilling writes:
> > Well, I found a solution: as many of the Sun tar features are undocumented,
> > we just rename /usr/bin/tar to /usr/bin/otar at the same time /usr/bin/tar
> > becomes a link to /usr/bin/star. As Sun customers cannot rely in
> > undocumented
> > features, star would only need to implelent compatibility to everything that
> > was documented in the public on June 25th 2007 in oder to get the permission
> > to replace the current /usr/bin/tar
> >
> > /usr/bin/otar would need to stay for a while until no Sun customer is
> > interested
> > in these undocumented features anymore.
>
> You're free to do that in your own distribution, but such a thing
> would be unlikely to happen soon in Solaris.
>
> 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.
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
options that are missing from Sun tar (not counting the find(1) CLI that is
integrated into star).
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
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.
This of course includes the knowledge that star is not a simple "tar".
Star is rather an "archiver library" that usually installs star as the main
binary and additional names as links. The full list of names currently is:
star The main binary name that implements a CLI which is a superset
if the functions that can be found in all archivers by implementing
an extended tar CLI syntax. The "star" CLI is as POSIX compliant
as possible for a program that implements an extended tar interface.
gnutar An emulation for GNU tar but without the usual GNU tar bugs ;-)
It emulates ~ GNU-tar 1.14 ignoring the useless (besause non-functional)
features like incremental backup and multi-volume. Star implements
it's own and functional variants of these features.
scpio An emulation of the SVr4 cpio interface. It only misses only the
undocumented support for UNIX V7 archives.
If you like to unpack other peoples cpio archives, it has a big
advantage over SUN's cpio: it autodetects and auto-applies the archive
type and the byte swapping and it implements POSIX.1-2001 extensions.
spax Something between SUSv2 pax and UNIX-03 pax. It implements much more
than SUSv2 defines but not everything from UNIX-03. It does not really
implement less than the pax Sun is using. Sun's /usr/bin/pax implement
parts that are missing in star but star implements a lot that is missing
in the current /usr/bin/pax. As star is 100% free and CDDL, it could
make sense to replace /usr/bin/pax by a link to star.
suntar
tar A nearly comlete implementation of the Sun tar CLI and feature list.
ustar You get the full star CLI, but the default tarchive format is
POSIX.1-1988 without any "enhancement".
For the first step of integrating star into Solaris, we would need to remove the
"tar" link.
> 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.
> acceptable change after such an EOF would likely require quite a bit
> of detailed investigation (and wouldn't be appropriate to do in an
> ad-hoc way on a broad mailing list like this).
>
> There may well be other reasons to avoid such a change for Solaris,
> including star's use of non-POSIX command line options. See:
>
> http://www.opensolaris.org/os/community/arc/caselog/1991/031/
> http://www.opensolaris.org/os/community/arc/caselog/1999/645/
> http://www.opensolaris.org/os/community/arc/caselog/2003/035/
It seems that you did never read recent related primary information from the
POSIX standard or that you missunderstand the POSIX CLI guidelines.
- POSIX mentions getopt() but it does not mandate that a
program needs to _use_ getopt() in order to implement a POSIX CLI.
- All my programs use getargs(), which exists since 1982 (getopt() is
from 1984). Getargs() is to my best knowledge fully POSIX compliant
but offers a lot more features than getopt() and any known
getopt_long() implementation.
- POSIX does not forbid long options, but POSIX will (currently)
not add long options to programs that are inside the POSIX
specification.
- The "tar" CLI was never inside a POSIX spec, but only in
UNIX-98 (SUSv2).
- "tar", "ar" and "dd" do not follow the POSIX CLI spec and do
not need to.
- 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.
You did quote Joseph Kowalski but in the private discussions I had with
him, he did never mention a CLI problem..... It seems you need to understand
the constraints under which he did write the ARC cases you quoted above.
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED] (uni)
[EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
