Date: Thu, 9 Aug 2018 09:49:44 -0700 (PDT) From: "Rodney W. Grimes" <freebsd@pdx.rh.CN85.dnsmgr.net> To: "Andrey V. Elsukov" <bu7cher@yandex.ru> Cc: rgrimes@freebsd.org, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r337536 - head/sbin/ipfw Message-ID: <201808091649.w79GniZf018408@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <640fc2e6-9332-2b59-c6ad-b0fd42dae7f2@yandex.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
-- 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201808091649.w79GniZf018408>