From owner-svn-src-all@freebsd.org Mon Aug 26 18:37:20 2019 Return-Path: Delivered-To: svn-src-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3558DE263E; Mon, 26 Aug 2019 18:37:20 +0000 (UTC) (envelope-from sucanjan@gmail.com) Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com [IPv6:2a00:1450:4864:20::443]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46HLMg1BJmz3HhB; Mon, 26 Aug 2019 18:37:18 +0000 (UTC) (envelope-from sucanjan@gmail.com) Received: by mail-wr1-x443.google.com with SMTP id y8so16264423wrn.10; Mon, 26 Aug 2019 11:37:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=RNXkOeV3VkCJxwlq7AgAfVBjBWH5dL+gIwc8h2J3Y5w=; b=IhLbl1nUCxb7qsexGD9i5aB8fi/FqiNMm6kX+YLSVwJpICIGvrv97Wl8lNfjEhA+tq UupSM/YGZcprO/pB1AD7HtMD8zunYIEnXojJ4IUyPM4hid10baNXsVcCtGh72UUs6wOx CerEL90u/m/ZHd/cnMh8C5LaGo54OHfDXG7rD//GefnGZvQ7zZ/2LRLGkOe6BdGyTjGR ulJu12d8qr98IwKlPc0T/JAdKtA9082dMAyp6ADjrfkSWUYc5mU9cJxtCu1KgBTqwsFs AOPF9/jU+bb5otmC6g0n86KeDcPmZFn+vA//xdwM4Sk3O1/0m2+FpLkZZ/ajb3XjrXmz hEfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=RNXkOeV3VkCJxwlq7AgAfVBjBWH5dL+gIwc8h2J3Y5w=; b=OQugWpQ1n4nzNZ1vO8mWTQK499d2yWOtKs6IcFunKaKpBt5JZkBYAdYZdRWbX0dLF8 n4NEkEuWexYEr6uZaYn9wyqPW+yRtpjndcolDd9J+M2f4vNLD0PwMhLbj6BBt+6p7F9S ftacR1KptAq0Lk7F01Bjmsa5qrJtkWabkYO+S9m3P/i/j3YFb7mD/ZazOJoqvzLNbDBf dkwjMTx0TpkrOeaqizE2SQ62dRdSEwNbXl11Eby7Q52NygYV02i0TWcsWNrS2Dnbmzfm PljzP5NQ0IYOu748MxUHKKH2nHL62aHXmlLDo+aSd5YiRGa9lutp93SGiPq0eMzYzAbb xV0A== X-Gm-Message-State: APjAAAUvO3a9C4ru4dCHvSA5cABlCdpQobcrOeBou3mKA5Fk61Tvtk50 aIhdscj1TJaEmjrZ0cneEL5DUHMhxRcRRQ== X-Google-Smtp-Source: APXvYqxXt84afNROsx9T2xH4PeS5jIkS308uT4gFTqWRKiI0XaQ9zb5u0e7oUYXwqJavUtlIqBuIWg== X-Received: by 2002:a5d:698f:: with SMTP id g15mr25304890wru.310.1566844637384; Mon, 26 Aug 2019 11:37:17 -0700 (PDT) Received: from [192.168.1.102] (9.215.broadband18.iol.cz. [109.81.215.9]) by smtp.gmail.com with ESMTPSA id s192sm213920wme.17.2019.08.26.11.37.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Aug 2019 11:37:16 -0700 (PDT) Subject: Re: svn commit: r351423 - in head: . sbin/ping6 sbin/ping6/tests To: Alan Somers , "Conrad E. Meyer" Cc: Hiroki Sato , src-committers , svn-src-all , svn-src-head References: <201908231522.x7NFMLuJ068037@repo.freebsd.org> <20190826.042056.1329861772202588895.hrs@allbsd.org> <20190826.050922.1810654532466043358.hrs@allbsd.org> From: Jan Sucan Message-ID: Date: Mon, 26 Aug 2019 20:37:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Rspamd-Queue-Id: 46HLMg1BJmz3HhB X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=IhLbl1nU; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of sucanjan@gmail.com designates 2a00:1450:4864:20::443 as permitted sender) smtp.mailfrom=sucanjan@gmail.com X-Spamd-Result: default: False [-3.95 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; RCPT_COUNT_FIVE(0.00)[6]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.95)[-0.945,0]; RECEIVED_SPAMHAUS_PBL(0.00)[9.215.81.109.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (2.55), ipnet: 2a00:1450::/32(-3.00), asn: 15169(-2.33), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[3.4.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; RCVD_TLS_ALL(0.00)[] X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2019 18:37:20 -0000 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 I forgot to answer the question whether it would be straightforward. It depends on how fast it should be solved. Simple and quick solution would be to completely duplicate the getopt loop including parsing of arguments of the options. With some more time I would implement it in two commits. The first commit for separating parsing of command line tokens from parsing of the option arguments, the second commit for translation of the options. I'm going to do it the second way. If the time is important, let me know. -Jan > On Sun, Aug 25, 2019 at 5:51 PM Conrad Meyer 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 wrote: >>> On Sun, Aug 25, 2019, 2:11 PM Hiroki Sato wrote: >>>> Alan Somers wrote >>>> in : >>>> >>>> as> On Sun, Aug 25, 2019 at 1:22 PM Hiroki Sato wrote: >>>> as> > >>>> as> > Hi, >>>> as> > >>>> as> > Alan Somers wrote >>>> as> > in <201908231522.x7NFMLuJ068037@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 >>>> 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?