In message <201908260229.x7q2tmsm074...@gndrsh.dnsmgr.net>, "Rodney W. Grimes" writes: > [ Charset UTF-8 unsupported, converting... ] > > 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 o > r > > > 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. > > Only incompatible in mind. $0 can easily be used to determine which > set of getopt() to process in a single binary that then has unduplicated > code to implement the set of final options. A bit more to code but > should achive the single binary linked by 2 names processing 2 different > option sets executing 1 set of common code. > > I am firmyly in the camp these changes are being made to well estabilish > and probably heavily used utility by both humans and shell scripts. > > I was not happy with the changes to -n, but sat silient on that issue, > with other things being done I need to chime in and say I think that > this is poorly tought out with respect to downstream impact. > > > > > 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? > > How does a copy in ports of the old ping6 code "remove duplicate code", > that just changes the location of the duplication out of base where it > shall certainly rot as unmaintained causing numerious consumers heart > ache over time.
Ports is a big issue, especially considering we're supporting previous versions of FreeBSD (stable/11 & stable/12) with an inconsistent ping6. Also agreed regarding checking *argv[0] to determine which getopt() to use. While we're at giving ping options some love and attention, shouldn't we also use getopt_long()? It is 2019 for that matter, and almost 2020 in a few months. > > -- > Rod Grimes rgri...@freebsd.or > g > -- Cheers, Cy Schubert <cy.schub...@cschubert.com> FreeBSD UNIX: <c...@freebsd.org> Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. _______________________________________________ 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"
