svn commit: r337536 - head/sbin/ipfw

[Andrey V. Elsukov]

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?

-- 
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-all/attachments/20180809/e8626b10/attachment.sig>