Joseph Kowalski writes: > I *think* Joerg's position was that star should be /usr/bin/star (as > opposed to /usr/sfw/bin/star), but *not* a replacement for tar.
Even as /usr/bin/star, I don't see a reason to overturn 2007/394. That case noted that there was _no_ common flag available for the work described in section 4.1 of 2007/315 and thus selected '-/' and '-%' for its work. When I reviewed 2007/315, I didn't know that it involved a cascade of new options for those utilities. I expected the utilities to change, but not in the command line. This series of cases has been a surprise. Personally, I'd like to do in both '@' and '/' as modifiers for programs like tar and cp. It'd make more sense to me if these utilities always copied all of the information available when both source and target support the operation rather than growing new hairball options every time we tweak a file system somewhere. That might just be me, though. > There was supposed to be a "statement of intent" that star would > eventually replace tar. > > Had this happened, then it is clear that conflicts between tar and > tar would have been addressed. Yes, but if that had happened, we would have said: the project proposing this new tar implementation came later to the ARC (and into OpenSolaris), so make it compatible with the previous projects or explain some better way forward. The current 'star' command appears to have some 151 separate options. Conflicts seem likely. And, as Don has correctly noted, it defaults to stripping the leading '/' from extracted files, which is helpful for security, but is both a POSIX violation and a clearly incompatible behavior. It can't be the default tar without changes. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> 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
