Date: Thu, 9 Aug 2018 10:01:48 -0700 (PDT) From: "Rodney W. Grimes" <freebsd@pdx.rh.CN85.dnsmgr.net> To: Ian Lepore <ian@freebsd.org> Cc: rgrimes@freebsd.org, "Andrey V. Elsukov" <bu7cher@yandex.ru>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r337536 - head/sbin/ipfw Message-ID: <201808091701.w79H1mgh018527@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <1533833774.9860.116.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Thu, 2018-08-09 at 09:49 -0700, Rodney W. Grimes wrote:
> > -- Start of PGP signed section.
> > [ Charset UTF-8 unsupported, converting... ]
> > >
> > > 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?
> > In spirit yes, in implementation No:
> >
> > The -f option is documented, and actually does, something different
> > than what your change would implement.
> >
> > ?????-f??????Do not ask for confirmation for commands that can cause
> > problems
> > ?????????????if misused, i.e., flush.??If there is no tty associated
> > with the
> > ?????????????process, this is implied.
> >
> >
> >
> >
>
> What he proposes is pretty much the exact behavior of rm -f, and should
> be intuitively obvious to anyone familiar with common unix commands.
And saddly that someone choose to use -f differently in ipfw, just
because it is intuatively obvious it is in direct conflict with
both the man page and the implemented code. This would just be
another overloading of an option to do 2 different things on 2
different sub commands. Are you really advocating going down that
slipperly slope?
--
Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201808091701.w79H1mgh018527>