Date: Thu, 9 Aug 2018 10:32:10 -0700 (PDT) From: "Rodney W. Grimes" <freebsd@pdx.rh.CN85.dnsmgr.net> To: "Andrey V. Elsukov" <bu7cher@yandex.ru> Cc: "rgrimes@freebsd.org" <rgrimes@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org> Subject: Re: svn commit: r337536 - head/sbin/ipfw Message-ID: <201808091732.w79HWAU1018694@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <4860211533835727@sas1-dc4267721c1f.qloud-c.yandex.net>
index | next in thread | previous in thread | raw e-mail
[ text/html is unsupported, treating like TEXT/PLAIN ]
Can you resend in none html format please?
> <br /><br />19:50, 9 августа 2018 г., "Rodney W. Grimes" <freebsd@pdx.rh.cn85.dnsmgr.net>:<br /><blockquote><p>-- Start of PGP signed section.<br />[ Charset UTF-8 unsupported, converting... ]<br /></p><blockquote> On 09.08.2018 19:19, Rodney W. Grimes wrote:<br /> >>>> table add/delete commands had the same behavior, "nat" already noted in<br /> >>>> this list. What is the usage scenario do you use, where you need to fail<br /> >>>> on bad delete?<br /> >>><br /> >>> if [ ipfw delete ${1} ]; then<br /> >>> handle the missing rule<br /> >>> fi<br /> >><br /> >> This is mostly unneeded operation, that we wanted to avoid.<br /> >> I.e. to be able run in bath mode:<br /> >><br /> >> delete ${n}<br /> >> add ${n} ...<br /> > <br /> > That is one use case, but any shell script worth writting<br /> > is worth writting to handle error conditions, and not being<br /> > able to handle errors while being silent is a PITA.<br /><br /> Ok, I still don't understand the usefulness of knowing the error<br /> code of delete command. But, I can propose the following solution:<br /> Index: ipfw2.c<br /> ===================================================================<br /> --- ipfw2.c (revision 337541)<br /> +++ ipfw2.c (working copy)<br /> @@ -3314,7 +3314,7 @@ ipfw_delete(char *av[])<br /> }<br /> }<br /> }<br /> - if (exitval != EX_OK && co.do_quiet == 0)<br /> + if (exitval != EX_OK && co.do_force == 0)<br /> exit(exitval);<br /> }<br /><br /><br /> With this patch -q will work as "quiet", -f will work as "force".<br /> So, you can still get error code in shell script, and I can run batched<br /> commands with -q -f:<br /><br /> # ipfw -f delete <span>10000-11000</span> ; echo $?<br /> ipfw: no rules rules in <span>10000-11000</span> range<br /> 0<br /> # ipfw -qf delete <span>10000-11000</span> ; echo $?<br /> 0<br /> # ipfw -q delete <span>10000-11000</span> ; echo $?<br /> 69<br /><br /> Are you fine with this?<br /></blockquote><p>In spirit yes, in implementation No:<br /><br />The -f option is documented, and actually does, something different<br />than what your change would implement.<br /><br /> -f Do not ask for confirmation for commands that can cause problems<br /> if misused, i.e., flush. If there is no tty associated with the<br /> process, this is implied.<br /></p></blockquote>But this option means "force", with -f ipfw(8) will not ask any questions and forcebly execute the command. The description in man page can be modified to correctly describe the case. <br /><br />Отправлено из мобильной Яндекс.Почты: http://m.ya.ru/ymail
--
Rod Grimes rgrimes@freebsd.org
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201808091732.w79HWAU1018694>