From owner-svn-src-all@freebsd.org Thu Aug 9 16:56:17 2018 Return-Path: Delivered-To: svn-src-all@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 C33CF106C9F2 for ; Thu, 9 Aug 2018 16:56:17 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (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 4F4947DB8A for ; Thu, 9 Aug 2018 16:56:17 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-RoutePath: aGlwcGll X-MHO-User: 20249bc6-9bf5-11e8-93fa-f3ebd9db2b94 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.ore.mailhop.org (Halon) with ESMTPSA id 20249bc6-9bf5-11e8-93fa-f3ebd9db2b94; Thu, 09 Aug 2018 16:56:15 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w79GuEq8059156; Thu, 9 Aug 2018 10:56:14 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1533833774.9860.116.camel@freebsd.org> Subject: Re: svn commit: r337536 - head/sbin/ipfw From: Ian Lepore To: rgrimes@freebsd.org, "Andrey V. Elsukov" Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Date: Thu, 09 Aug 2018 10:56:14 -0600 In-Reply-To: <201808091649.w79GniZf018408@pdx.rh.CN85.dnsmgr.net> References: <201808091649.w79GniZf018408@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-all@freebsd.org X-Mailman-Version: 2.1.27 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: Thu, 09 Aug 2018 16:56:17 -0000 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. -- Ian