Sven Joachim <firstname.lastname@example.org> (18/07/2009): > This looks strange, it seems that the test found update-menus > executable, but it no longer is. Namely, the shell has apparently > hashed it, since otherwise you would "update-menus: command not found" > instead of "permission denied". > > This may be because the dpkg trigger for update-menus had been > activated. Can you examine your dpkg.log entries of the failed > upgrade? (No sign of triggers, it's just that emacs21 gets configured before menu.) That one might be arch-related: | kbsd:/home/kibi# which update-menus | /usr/bin/update-menus | kbsd:/home/kibi# ls -l /usr/bin/update-menus | -rw-r--r-- 1 root root 113028 jun 8 13:13 /usr/bin/update-menus That's on GNU/kFreeBSD. I still have to investigate why, but it looks like if [ -x /usr/bin/update-menus ] returns true even with the above-mentioned conditions. Cc'ing -bsd. > > And also, under zsh: > > | $ which doublefailure 2>/dev/null > > | doublefailure not found > > > > Leading to: > > | if [ -x `which icanhazfailure 2>/dev/null` ] ; then echo FAIL ; fi > > | [: too many arguments > > This is missing the double quotes that are present in the debhelper > script snippet. Thanks to them, there is only one argument for [ -x . Indeed, thanks. /me gets back to fixing (real) bugs. Mraw, KiBi.
Description: Digital signature