Date: Thu, 9 Aug 2018 08:48:08 -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: <201808091548.w79Fm8Ed018168@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <1511fb63-89f9-14a9-32df-6706b5a9e93c@yandex.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 09.08.2018 17:40, Rodney W. Grimes wrote:
> >>> So now I can not code a quiet ipfw command that does fail when
> >>> I give it a bad delete command :-(.
> >>
> >> Previously -q did not handled by delete command, so you can just use bad
> >> "ipfw delete" without -q :)
> >
> > This now means -q has 2 functions, silence most commands,
> > and silently ignore errors on delete.
> >
> > That is a poor implementation of syntax and options.
>
> I think it makes "delete" command to have the same behavior as described
> for commands in "-q" description:
Which is yet another bug in your commit, you did not update the
synopsis or the description of the -q flag to include your
change. Though oddly the synopsis does show delete -q, it
how ever does not show -q for any of the table commands.
>
> -q Be quiet when executing the add, nat, zero, resetlog or flush
> commands; (implies -f).
No mention of what it does on delete, does -q on delete imply -f?
> This is useful when updating rulesets by
> executing multiple ipfw commands in a script (e.g.,
> ?sh?/etc/rc.firewall?), or by processing a file with many ipfw
> rules across a remote login session. It also stops a table add
> or delete from failing if the entry already exists or is not
> present.
That suggesting that -q is good for remote login session is
poor advice at best, you should redirect both standard and
error output to a file, depending on -q is just a loaded
gun waiting to go off.
>
> 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
But more importantly you seem to be ignoring the aspect that
your overloading a "silent" option with a "ignore failure"
option. That is bad design. The description of the -q flag
is already 2x as long as it should be in a good design.
--
Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201808091548.w79Fm8Ed018168>