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: aide: dotlockfile presence test incorrect
Package: aide Version: 0.11a-3 Severity: normal The test for the presence of dotlockfile is incorrect. It fails to detect if dotlockfile is not installed. if [ -x $(which dotlockfile) ]; then ... else echo 2 no dotlockfile binary in path, not checking for already running aide fi However if dotlockfile is not found then it expands to a newline and the test for -x on a newline is true. test -x $(which does-not-exist) echo yes || echo no yes test -x $(echo) echo yes || echo no yes 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 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 Thanks Bob -- Bob Proulx [EMAIL PROTECTED] http://www.proulx.com/~bob/ -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-3-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages aide depends on: ii liblockfile1 1.06NFS-safe locking library, includes -- 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]