Bug#367333: [Pkg-aide-maintainers] Bug#367333: aide: dotlockfile presence test incorrect
tags #367333 confirmed pending thanks On Mon, May 15, 2006 at 09:51:05AM +0200, Marc Haber wrote: if command -v dotlockfile /dev/null 21; then ... else echo 2 no dotlockfile binary in path, not checking for already running aide fi seems to do the job. Can you verify? I have decided to keep the dotlockfile presence check with the new, correct command -v idiom and have committed the change to svn. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#367333: [Pkg-aide-maintainers] Bug#367333: aide: dotlockfile presence test incorrect
On Mon, May 15, 2006 at 12:48:52AM -0600, Bob Proulx wrote:
The test for the presence of dotlockfile is incorrect. It fails to
detect if dotlockfile is not installed.
Thanks for spotting this.
if [ -x $(which dotlockfile) ]; then
...
else
echo 2 no dotlockfile binary in path, not checking for already running
aide
fi
I'll probably remove the check since aide depends on liblockfile1 in
these days, and thus dotlockfile is guaranteed to be present.
Objections?
The developers reference contains some suggestions for dealing with
this type of situation.
http://www.us.debian.org/doc/developers-reference/ch-best-pkging-practices.en.html#s-bpp-debian-maint-scripts
Yes, and it also says that using which is an acceptable alternative
for scripts that don't run early in system startup.
Here is a suggested fix based upon those recommendations. Although
many other good solutions also exist.
pathfind() {
OLDIFS=$IFS
IFS=:
for p in $PATH; do
if [ -x $p/$* ]; then
IFS=$OLDIFS
return 0
fi
done
IFS=$OLDIFS
return 1
}
if pathfind dotlockfile; then
if ! dotlockfile -p -l $LOCKFILE; then
echo 2 cannot obtain lock $LOCKFILE, stale lock?
exit 1
fi
else
echo 2 no dotlockfile binary in path, not checking for already running
aide
fi
I hate that idea. Huge complexity added.
Greetings
Marc
--
-
Marc Haber | I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#367333: [Pkg-aide-maintainers] Bug#367333: aide: dotlockfile presence test incorrect
Marc Haber wrote: I'll probably remove the check since aide depends on liblockfile1 in these days, and thus dotlockfile is guaranteed to be present. Objections? That would be fine. Anything that simplifies the script is a good thing in my mind. Yes, and it also says that using which is an acceptable alternative for scripts that don't run early in system startup. In Debian use of 'which' is fine. (On Debian 'which' is a shell script with different behavior than traditional systems. On other systems 'which' is a csh script and has different behavior not suitable to this task. But on Debian it is fine.) I hate that idea. Huge complexity added. I am okay with the use of 'which' to detect the command. As it was I was simply following the published guidelines. Avoiding this entirely and using the package dependency I like better. But since the test was there in the script I assumed that it was the maintainer's preference to have a test there. Bob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#367333: [Pkg-aide-maintainers] Bug#367333: aide: dotlockfile presence test incorrect
On Mon, May 15, 2006 at 09:34:31AM +0200, Marc Haber wrote: On Mon, May 15, 2006 at 12:48:52AM -0600, Bob Proulx wrote: The test for the presence of dotlockfile is incorrect. It fails to detect if dotlockfile is not installed. Thanks for spotting this. if [ -x $(which dotlockfile) ]; then ... else echo 2 no dotlockfile binary in path, not checking for already running aide fi I'll probably remove the check since aide depends on liblockfile1 in these days, and thus dotlockfile is guaranteed to be present. Objections? otoh, if command -v dotlockfile /dev/null 21; then ... else echo 2 no dotlockfile binary in path, not checking for already running aide fi seems to do the job. Can you verify? Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#367333: [Pkg-aide-maintainers] Bug#367333: aide: dotlockfile presence test incorrect
Marc Haber wrote: otoh, if command -v dotlockfile /dev/null 21; then ... else echo 2 no dotlockfile binary in path, not checking for already running aide fi seems to do the job. Can you verify? Your new code suggestion works fine and is an idiom that I have used often in shell scripts. So if you are okay with it then I am too. I am not aware of any situation in Debian (for example /bin/sh is really ash, dash, etc.) where this does not work okay. If I recall correctly the use of 'command -v' is an XSI extension. I have seen people object to using XSI extensions previously. (shrug.) I could go either way on this and do not have a strong preference. Bob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#367333: [Pkg-aide-maintainers] Bug#367333: aide: dotlockfile presence test incorrect
On Mon, May 15, 2006 at 02:43:54AM -0600, Bob Proulx wrote: I am okay with the use of 'which' to detect the command. As it was I was simply following the published guidelines. Avoiding this entirely and using the package dependency I like better. But since the test was there in the script I assumed that it was the maintainer's preference to have a test there. If I recall correctly, the hard dependency on liblockfile1 was added pretty recently. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
