Bug 70821

Hmmm, what happens if you take the execute bit off?
That's been the traditional fix in rpmbuild for mis-identified
files since, well, forever.

Otherwise agreed, file(1) magic has burned me repeatedly.
It ain't as simple as looking for "#!", there's other
sicko uglix variants as well, and I won't go there unless
forced :-(

[ I posted something like this yesterday, but something clearly went awry ]

Nope, the offending file's not executable:

[root@cockatrice root]# echo /usr/X11R6/lib/X11/config/Win32.rules | /usr/lib/rpm/find-requires

XCOMM
[root@cockatrice root]# ls -l /usr/X11R6/lib/X11/config/Win32.rules 
-r--r--r--    1 root     root        15850 Jun 25 20:11 /usr/X11R6/lib/X11/config/Win32.rules

What do you mean by "sicko uglix variants"?  As far as I can see, the
later code which processes $scriptlist comes pretty close to assuming
a #! line anyway.  It certainly won't cope with the generality of
things that file(1) marks as "script" or "commands".

Created attachment 69284 [details]
Patch to use #! instead of file(1) to detect scripts

Sorry to be obscure. There are, of course,
many ways other than #! to associate a script
with it's interpreter. From memory (examples
throughout xemacs), one can do something like
	: exec /usr/bin/perl ...
which breaks find-requires. Your patch is OK,
but will fail if, say, there are multiple
occurences that happen to match '#!'

I'd suggest that file(1) is not the problem, but /etc/magic
tends to rot unexpectedly. One way out of the dilemma
is to use file(1), but with a "known good" /usr/lib/rpm/magic
file.

I'm gonna defer this to rpm-4.2 ...

Two points (neither directly relevant until you decide to fix the problem:

1: My patch shouldn't pay attention to #! other than at the start of the
   first line of a file.  The grep '^[^:]*:1:' is what ensures this.  On 
   the other hand, grepping the whole of every file is likely to be 
   ludicrously slow, so a for loop and head is probably a better idea.

2: The code that catches makefiles is in ascmagic.c, so putting in a new
   magic file won't help directly:

  [root@honey root]# file -m /dev/null /usr/X11R6/lib/X11/config/Win32.rules 
  file: Using regular magic file `/dev/null'
  /usr/X11R6/lib/X11/config/Win32.rules: ASCII make commands text

Actually, find-requires _is_ checking whether each alleged script is
executable.  The problem is that test(1) is screwing up and claiming
that Win32.rules is executable when it isn't:

[root@honey root]# ls -l /usr/X11R6/lib/X11/config/Win32.rules
-r--r--r--    1 root     root        15850 Jul 26 14:11 /usr/X11R6/lib/X11/config/Win32.rules
[root@honey root]# [ -x /usr/X11R6/lib/X11/config/Win32.rules ]
[root@honey root]# echo $?
0

Whereas on a RHL 7.3 system:

hydra:~$ ls -l /usr/X11R6/lib/X11/config/Win32.rules
-r--r--r--    1 root     root        15850 Apr 19 04:10 /usr/X11R6/lib/X11/config/Win32.rules
hydra:~$ [ -x /usr/X11R6/lib/X11/config/Win32.rules ]
hydra:~$ echo $?
1

*sigh*

Off to get test(1) (in bash builtin) fixed. Please bounce back to rpm
for further find-requires fixing afterwards.

Doesn't happen here... 
 
[root@zell SPECS]# ls -l /usr/X11R6/lib/X11/config/Win32.rules 
-r--r--r--    1 root     root        15850 Jul 27 00:00 
/usr/X11R6/lib/X11/config/Win32.rules 
[root@zell SPECS]# [ -x /usr/X11R6/lib/X11/config/Win32.rules ] 
[root@zell SPECS]# echo $? 
1 
[root@zell SPECS]# rpm -q bash sh-utils 
bash-2.05b-2 
sh-utils-2.0.12-2 
[root@zell SPECS]# echo $SHELL 
/bin/bash 
 
Presuming it was fixed between limbo and today; assigning back.

So what's the problem with '[' in your bash?

That's what I'd like to know.  I'm getting the same behaviour on two separate
systems.

stracing bash gives the following relevant-looking information:
access("foo", X_OK)                     = 0

(where foo isn't executable according to ls)

Ah, and it looks like we were running an old kernel version.  Upgrading to
2.4.18-7.80 cleared it up.

Sorry to have bothered you!