svn commit: r337536 - head/sbin/ipfw

[Rodney W. Grimes]

> 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 at freebsd.org