> On Oktober 25, 2007 14:10:43 +0200 Ansgar -59cobalt- Wiechers wrote:
>> On 2007-10-24 Paolo wrote:
> [...]
>>> $iptables -t mangle -P OUTPUT ACCEPT &&\
>>> $iptables -t mangle -P INPUT ACCEPT &&\
>>> $iptables -t mangle -P POSTROUTING ACCEPT &&\
>>> echo "Policing .......................................... [ OK ]" || {
>>> echo "Something broke in 'Policing'!"
>>> exit 1
>>> }
>>
>> You don't want to do that, because the term in curled braces is
>> executed when *any* of the previous commands fails (including the
>> echo).
>
> This is a Debian list. Debian uses bash as /bin/sh. Bash has echo as
> an builtin which always returns exit status 0, so it never fails.
I'm aware of all that, except for the "always returns 0" bit (thanks for
the info). However, my point wasn't that in this particular case echo
would fail (or even were likely to fail), but that the construct
"command && command_on_success || command_on_error" in general is flawed
and should be avoided.
> Also, when a script is not even able to output its diagnostics, I
> would consider this as a failure too (guarding against failure of echo
> would be nice when enabling/disabling IP forwarding ...).
Agreed, but besides my point.
> On the other hand, echoing error messages when a previous echo failed
> is, ahemm, not very productive, at least writing the error messages
> to syslog via logger (at level "err" or higher) would IMHO be
> advisable.
Heh. Yeah, good point.
Regards
Ansgar Wiechers
--
"The Mac OS X kernel should never panic because, when it does, it
seriously inconveniences the user."
--http://developer.apple.com/technotes/tn2004/tn2118.html
--
To UNSUBSCRIBE, email to debian-firewall-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
No comments:
Post a Comment