From owner-svn-src-head@freebsd.org Thu Aug 9 16:49:53 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 40F16106C664; Thu, 9 Aug 2018 16:49:53 +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 A85B67D555; Thu, 9 Aug 2018 16:49:52 +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 w79Gni0G018409; Thu, 9 Aug 2018 09:49:44 -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 w79GniZf018408; Thu, 9 Aug 2018 09:49:44 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <201808091649.w79GniZf018408@pdx.rh.CN85.dnsmgr.net> Subject: Re: svn commit: r337536 - head/sbin/ipfw In-Reply-To: <640fc2e6-9332-2b59-c6ad-b0fd42dae7f2@yandex.ru> To: "Andrey V. Elsukov" Date: Thu, 9 Aug 2018 09:49:44 -0700 (PDT) CC: rgrimes@freebsd.org, 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-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 16:49:53 -0000 -- 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. -- Rod Grimes rgrimes@freebsd.org