From owner-svn-src-all@freebsd.org Thu Aug 9 17:01:51 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 5881C106D023; Thu, 9 Aug 2018 17:01:51 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C7EDF7E115; Thu, 9 Aug 2018 17:01:50 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w79H1mew018528; Thu, 9 Aug 2018 10:01:48 -0700 (PDT) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w79H1mgh018527; Thu, 9 Aug 2018 10:01:48 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <201808091701.w79H1mgh018527@pdx.rh.CN85.dnsmgr.net> Subject: Re: svn commit: r337536 - head/sbin/ipfw In-Reply-To: <1533833774.9860.116.camel@freebsd.org> To: Ian Lepore Date: Thu, 9 Aug 2018 10:01:48 -0700 (PDT) CC: rgrimes@freebsd.org, "Andrey V. Elsukov" , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Reply-To: rgrimes@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII 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 17:01:51 -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. 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? -- Rod Grimes rgrimes@freebsd.org