Hello,
I can implement it. I suppose that ping6's manual page should be kept it
this case.
I was also thinking about printing a warning for each option renamed to
lead a willing user to use the new unified option set of ping. It could
be either only with -v, or by default and suppressed with -q. Or should
the option translation be completely transparent?
-Jan
On 26. 8. 2019 1:58, Alan Somers wrote:
Jan (please keep him CCed on replies) has been musing about the same
thing. That might satisfy everyone. Jan, would it be straightforward
to implement?
-Alan
On Sun, Aug 25, 2019 at 5:51 PM Conrad Meyer <c...@freebsd.org> wrote:
Hi Alan, Hiroki,
It would be pretty easy to install a `ping6` link to the `ping(8)`
binary with different option parsing (conditional on argv[0]). That
removes most of the issues of code and space duplication, I think?
And the goal would be for the 'ping6' name to retain option
compatibility with historical ping6.
It's not an uncommon pattern; for example, 'id', 'groups', and
'whoami' are all a single binary with multiple linked names. Another
example is Clang, which provides 'cc', 'c++', 'clang', 'clang-cpp',
'clang++' and 'cpp' links to the same inode — and those have very
different behavior depending on argv[0].
It's less work than forcing the ping6 compatibility crowd to create a
port and doesn't hurt ping(8) much, AFAICT. Is it an acceptable
middle ground?
Best,
Conrad
On Sun, Aug 25, 2019 at 1:26 PM alan somers <asom...@gmail.com> wrote:
On Sun, Aug 25, 2019, 2:11 PM Hiroki Sato <h...@allbsd.org> wrote:
Alan Somers <asom...@freebsd.org> wrote
in <CAOtMX2hLxx=skvh1zoimacagqjjparsvkml9j+bgpqsz5un...@mail.gmail.com>:
as> On Sun, Aug 25, 2019 at 1:22 PM Hiroki Sato <h...@allbsd.org> wrote:
as> >
as> > Hi,
as> >
as> > Alan Somers <asom...@freebsd.org> wrote
as> > in <201908231522.x7nfmluj068...@repo.freebsd.org>:
as> >
as> > as> Author: asomers
as> > as> Date: Fri Aug 23 15:22:20 2019
as> > as> New Revision: 351423
as> > as> URL: https://svnweb.freebsd.org/changeset/base/351423
as> > as>
as> > as> Log:
as> > as> ping6: Rename options for better consistency with ping
as> > as>
as> > as> Now equivalent options have the same flags, and nonequivalent
options have
as> > as> different flags. This is a prelude to merging the two commands.
as> > as>
as> > as> Submitted by: Ján Sučan <sucan...@gmail.com>
as> > as> MFC: Never
as> > as> Sponsored by: Google LLC (Google Summer of Code 2019)
as> > as> Differential Revision: https://reviews.freebsd.org/D21345
as> >
as> > I have an objection on renaming the existing option flags in ping6(8)
as> > for compatibility with ping(8).
as> >
as> > Is it sufficient to add INET6 support to ping(8) with consistent
as> > flags and keep CLI of ping6(8) backward compatible? People have used
as> > ping6(8) for >15 years, so it is too late to rename the flags. I do
as> > not think the renaming is useful if "ping -6 localhost" or "ping ::1"
as> > works.
as> >
as> > -- Hiroki
as>
as> If ping works with inet6, then why would we want to keep a separate
as> tool around? If it's just for the sake of people who don't want to or
as> can't update scripts, would a version in ports suffice?
Because removing (or renaming) it causes a POLA violation. Do we
really have a strong, unavoidable reason to force people to rewrite
their script now? This is still a fairly essential and actively used
tool, not like rcp or rlogin. Although deprecating ping6(8) and
removing it from the base system in the future release at some point
may work, changing the existing interface will simply confuse people
who have used IPv6 for a long time.
In my understanding, the purpose to integrate ping(8) and ping6(8)
into a single utility is to provide a consistent CLI and reduce
duplicate code, not to break compatibility.
-- Hiroki
Those goals are incompatible. We can't provide a consistent CLI without
breaking compatibility because ping and ping6 have conflicting options. And we
can't keep ping6 around while also removing duplicate code because that would
be, well, duplicate code.
When would be a better time than a major version bump to make a change like
this?
The lack of a ping6 command in freebsd 13 should serve as a pretty obvious
reminder that scripts will need updating. I think that putting a version of
ping6 in ports should be a sufficient crutch for those who need it, don't you?
_______________________________________________
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
