On Sat, Jul 18, 2009 at 11:30:27PM +0200, Cyril Brulebois wrote: > Cyril Brulebois <[email protected]> (18/07/2009): > > Sven Joachim <[email protected]> (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. > > I guess the answer is in coreutils's lib/euidaccess.c; it'd be nice if > someone could have a look at it. >
Actually this file is not used, euidaccess() from the GNU libc is used. It calls in turn access() which is mapped to the syscall. And here comes the portability issue: | If the calling process has appropriate privileges (i.e., is | superuser), POSIX.1-2001 permits implementation to indicate success | for an X_OK check even if none of the execute file permission bits | are set. Linux does not do this. OTOH POSIX 2008 says: | New implementations are discouraged from returning X_OK unless at least | one execution permission bit is set. Maybe we should fix that in our glibc? -- Aurelien Jarno GPG: 1024D/F1BCDB73 [email protected] http://www.aurel32.net -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
