fredag den 3 december 2010 klockan 13:54 skrev Jakub Wilk detta: > * Alexander Reichle-Schmehl <toli...@debian.org>, 2010-12-03, 13:43: >>>> I'm looking at it now... Just one question, is there a reason why >>>> you use "rm $TEMPCONFFILE 2>/dev/null || true" instead of "rm -f >>>> $TEMPCONFFILE"? >>>> >>>> It's not wrong, but longer ;) >> >>> No really valid reason at all, only that the policy mandates maintainer >>> scripts to append the "or-true construct" to capture exceptional states. >> >> Yes, as many other programs don't allow you to catch things properly. >> >> As said: Using "||true" is not false, it's just uncommon ;) > > I'd argue that the "|| true" variant is wrong. > > "rm -f $something" ignores only non-existent files. > "rm $something 2>/dev/null || true" swallows all kind of possible > errors. This is almost never what you want.
Good point. But which error is such that I am allowed to let postinst stumble upon it in this particular case? According to policy it must be caught and returned back as an error code. The lack of "-f" in this case might theoretically (no "-i" present) lead to a prompt from "rm", but the setting and capabilities in which postinst is normally executed should make this extraordinarily unlikely. Right? In the particular case at hand, I am dealing with the removal of a temporary file, used with mktemp at creation time, so one small breach would be that a malicious intruded managed to find the file name, and to delete said file, before the purge action came to its conclusion. That is the only exceptional state I can think of in my case, but your distinction between "rm -f" and "or-true-compound" is well phrased and worth observing. Best regards, Mats E A -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101203135439.ga17...@mea.homelinux.org
