James Carlson <james.d.carlson at sun.com> wrote:
> Joerg Schilling writes:
> > 1) Don did get the approval for adding -/ to ls(1) only because he did
> > promise not to plan to do the same for tar(1).
>
> I've looked over PSARC 2007/394 (which added '-/' to ls), and I can't
> find any such promise. Can you provide a citation?
This is what I have in mind. I am not sure what Don relly mailed.
The discussion was about that clashes cannot be avoided, but this was done
under completely different constraints as it would be if tar(1) has to be
included in the list of commands that are affected.
If someone writes that there is no clash because we are not talking abut tar(1),
this claim is obviously no longer true and we even need to unroll the ls(1)
case
again.
> First of all, this isn't Don's proposal. The submitter (author) is
> Cynthia Eastham. Don is the sponsor. We do like to take Don "for
> serious," because he's a long-time PSARC intern and an expert in
> standards compliance, but withdrawing the case needs the submitter's
> consent as well.
This is not personal!
I am trying to point to a serious CLI compatibility problem that will be
introduced in case that tar(1), cpio(1) and/or pax(1) add a -/ option
as these progams already include such an option if you use the versions that
come with the star package.
> Secondly, one of our goals here is to avoid gratuitous differences
> among OpenSolaris interfaces. That means that if we can allocate the
> same option letter for ls(1), tar(1), and cp(1) for the same purpose,
> then we'll do so. This case is following multiple other cases
> (2007/394, 2007/410, 2007/432) that have incrementally added -/ and -%
> to various common utilities. Thus, this one is in fact preserving
> integrity among those commands by using the same option for the same
> purpose.
We _cannot_ allocate -/ for tar(1), cpio(1) and/or pax(1). So you also
seem to propose that we need to start again the discussion for ls(1).
> Finally, I don't see how we're under any obligation to avoid all
> possible conflicts with non-OpenSolaris command variants. Sure, it'd
> be nice if we could do so, and better still with a survey of more than
> just the "shilly" commands (avoiding GNU conflicts seems more
> important to me), but strict avoidance seems unlikely to happen.
tar(1) should be replaced by star in order to get a modern tar implementaion
on Solaris that offers the features that people like to see. pax(1) _needs_
to be replaced because the current version is Close Source. As the integration
of star has already been approved (case 2004/480) and as star is under CDDL,
it is obvious to replace the current /usr/bin/pax by a link to star.
> If you have a concrete proposal for how these options can be added in
I did already make a proposal for a better way to deal with the problem in June.
This was for the first arc case for ls(1).
> > is not in conflict with star(1), scpio(1) and spax(1). Note that
> > the pax command that Sun is currently using is closed source and if
> > Sun is really pushing OpenSource, Sun should replace the current
> > pax(1) binary by a link to the OpenSource (CDDL) star(1) command.
>
> That seems both wrong and off-topic. We're discussing changes to the
> OpenSolaris cpio(1), pax(1), and tar(1) commands, not replacement of
> those commands or the licenses or availability of the source.
I understand that ARC cases on Solaris are in order to grant long term
interface stability on Solaris.
The current arc case looks like an unplanned action similar to what I only know
with Linux. I was in hope that on Solaris there is a long term planning for
interfaces. Please do not try to propose to iplement "cheap" solutions that
just benefit the lazy programmer but harm the long term integrity of
OpenSolaris.
> > I would even recommend to rethinkg _all_ other commands that did
> > introduce -/ recently and replace -/ by something more apropriate
> > to allow a unique CLI interface.
>
> If any rethinking is done, I'd _insist_ that they all be done
> together. This piecemeal approach has been confusing at best, and
> consistency is highly desirable.
Thank you for supporting me! I don't like this too and I would loke to see
a complete arc case that includes all aspects of the global problem and
discusses possible solutions.
> That feedback has already been given to the project team, during ARC
> business when we discussed 2007/432. As this is expected to be the
> last of these cases, it needn't be repeated here, but I'll do so
> anyway: one case would have been better.
>
> > 2) The archive format for the planned feature is not documented.
>
> There's no new archive format here. Adding an option that uses an
> existing format doesn't sound like a reason to force documentation of
> what's already there.
>
> But if the project team could supply that documentation, that might be
> helpful to close the loop on 1999/209.
It is most unlikely that a case from 1999 includes support for file flags.
If file flags are introduced by adding special interpretations on the extended
attribute files, this needs to be documented.
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
