Date: Thu, 09 Aug 2018 11:15:06 -0600 From: Ian Lepore <ian@freebsd.org> To: rgrimes@freebsd.org Cc: "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: <1533834906.9860.118.camel@freebsd.org> In-Reply-To: <201808091701.w79H1mgh018527@pdx.rh.CN85.dnsmgr.net> References: <201808091701.w79H1mgh018527@pdx.rh.CN85.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 2018-08-09 at 10:01 -0700, Rodney W. Grimes wrote:
> >
> > 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?
>
>
Am I advocating for the ability to optionally silently not-fail on an
attempt to delete something that doesn't exist, using the exact same
syntax for that behavior as the standard rm(1) command uses?
Why, yes. Yes I am.
-- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1533834906.9860.118.camel>