svn commit: r337536 - head/sbin/ipfw

[Ian Lepore]

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.

-- Ian