svn commit: r337536 - head/sbin/ipfw

[Andrey V. Elsukov]

On 09.08.2018 18:48, Rodney W. Grimes wrote:
>>> 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

This is mostly unneeded operation, that we wanted to avoid.
I.e. to be able run in bath mode:

delete ${n}
add ${n} ...

> 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.

I have a feeling you are watching each my commit and comment it :)
I did not designed this behavior, at work we use another tool to work
with rules and tables. I'm fine with reverting this change. Do you want
to restore previous behavior?
AFAIR, julian@ complains that ipfw(8) has some error states that should
be removed.

-- 
WBR, Andrey V. Elsukov

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 554 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20180809/74103176/attachment.sig>