From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623
Description of problem:
/usr/lib/rpm/find-requires uses "file" to determine if something is a script,
and if so tries to get the interpreter from the first line. Unfortunately,
"file" describes some makefiles (notably one of the imakefile fragments shipped
as part of XFree86-devel) as "ASCII make commands text", causing find-requires
to look for a (non-existent) #! line. In the case of XFree86, this causes
find-requires to generate a requirement of "XCOMM".
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install XFree86-devel 4.2.0-52
2. echo /usr/X11R6/lib/X11/config/Win32.rules | /usr/lib/rpm/find-requires
Actual Results: find-requires outputs:
Expected Results: No output
An obvious better mechanism would be for find-requires to look for an initial #!
line in each file itself, rather than trusting "file" to do the job.
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
[ 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
[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
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 $?
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 $?
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
[root@zell SPECS]# [ -x /usr/X11R6/lib/X11/config/Win32.rules ]
[root@zell SPECS]# echo $?
[root@zell SPECS]# rpm -q bash sh-utils
[root@zell SPECS]# echo $SHELL
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
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!