From owner-svn-src-head@freebsd.org Thu Aug 9 17:15:19 2018 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8245C106D556 for ; Thu, 9 Aug 2018 17:15:19 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0721C7EA53 for ; Thu, 9 Aug 2018 17:15:18 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-RoutePath: aGlwcGll X-MHO-User: c349fc38-9bf7-11e8-aff6-0b9b8210da61 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id c349fc38-9bf7-11e8-aff6-0b9b8210da61; Thu, 09 Aug 2018 17:15:08 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w79HF6tu059207; Thu, 9 Aug 2018 11:15:06 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1533834906.9860.118.camel@freebsd.org> Subject: Re: svn commit: r337536 - head/sbin/ipfw From: Ian Lepore To: rgrimes@freebsd.org Cc: "Andrey V. Elsukov" , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Date: Thu, 09 Aug 2018 11:15:06 -0600 In-Reply-To: <201808091701.w79H1mgh018527@pdx.rh.CN85.dnsmgr.net> References: <201808091701.w79H1mgh018527@pdx.rh.CN85.dnsmgr.net> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2018 17:15:19 -0000 On Thu, 2018-08-09 at 10:01 -0700, Rodney W. Grimes wrote: > > > > On Thu, 2018-08-09 at 09:49 -0700, Rodney W. Grimes wrote: > > > > > > -- Start of PGP signed section. > > > [ Charset UTF-8 unsupported, converting... ] > > > > > > > > > > > > On 09.08.2018 19:19, Rodney W. Grimes wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > table add/delete commands had the same behavior, "nat" > > > > > > > > already noted in > > > > > > > > this list. What is the usage scenario do you use, where > > > > > > > > you > > > > > > > > need to fail > > > > > > > > on bad delete? > > > > > > > if [ ipfw delete ${1} ]; then > > > > > > > handle the missing rule > > > > > > > fi > > > > > > This is mostly unneeded operation, that we wanted to avoid. > > > > > > I.e. to be able run in bath mode: > > > > > > > > > > > > delete ${n} > > > > > > add ${n} ... > > > > > That is one use case, but any shell script worth writting > > > > > is worth writting to handle error conditions, and not being > > > > > able to handle errors while being silent is a PITA. > > > > Ok, I still don't understand the usefulness of knowing the > > > > error > > > > code of delete command. But, I can propose the following > > > > solution: > > > > Index: ipfw2.c > > > > =============================================================== > > > > ==== > > > > --- ipfw2.c (revision 337541) > > > > +++ ipfw2.c (working copy) > > > > @@ -3314,7 +3314,7 @@ ipfw_delete(char *av[]) > > > > ? } > > > > ? } > > > > ? } > > > > - if (exitval != EX_OK && co.do_quiet == 0) > > > > + if (exitval != EX_OK && co.do_force == 0) > > > > ? exit(exitval); > > > > ?} > > > > > > > > > > > > With this patch -q will work as "quiet", -f will work as > > > > "force". > > > > So, you can still get error code in shell script, and I can run > > > > batched > > > > commands with -q -f: > > > > > > > > # ipfw -f delete 10000-11000 ; echo $? > > > > ipfw: no rules rules in 10000-11000 range > > > > 0 > > > > # ipfw -qf delete 10000-11000 ; echo $? > > > > 0 > > > > # ipfw -q delete 10000-11000 ; echo $? > > > > 69 > > > > > > > > Are you fine with this? > > > In spirit yes, in implementation No: > > > > > > The -f option is documented, and actually does, something > > > different > > > than what your change would implement. > > > > > > ?????-f??????Do not ask for confirmation for commands that can > > > cause > > > problems > > > ?????????????if misused, i.e., flush.??If there is no tty > > > associated > > > with the > > > ?????????????process, this is implied. > > > > > > > > > > > > > > What he proposes is pretty much the exact behavior of rm -f, and > > should > > be intuitively obvious to anyone familiar with common unix > > commands. > And saddly that someone choose to use -f differently in ipfw, just > because it is intuatively obvious it is in direct conflict with  > both the man page and the implemented code.  This would just be > another overloading of an option to do 2 different things on 2 > different sub commands.  Are you really advocating going down that > slipperly slope? > > Am I advocating for the ability to optionally silently not-fail on an attempt to delete something that doesn't exist, using the exact same syntax for that behavior as the standard rm(1) command uses? Why, yes.  Yes I am. -- Ian