Bug 70821 - bash [ -x file ] gets it wrong (was find-requires broken)
bash [ -x file ] gets it wrong (was find-requires broken)
Product: Red Hat Public Beta
Classification: Retired
Component: rpm (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Johnson
Depends On:
  Show dependency treegraph
Reported: 2002-08-05 15:35 EDT by Ben Harris
Modified: 2008-05-01 11:38 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-08-12 12:59:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Patch to use #! instead of file(1) to detect scripts (575 bytes, patch)
2002-08-07 10:51 EDT, Ben Harris
no flags Details | Diff

  None (edit)
Description Ben Harris 2002-08-05 15:35:03 EDT
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):

How reproducible:

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

Additional info:

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.
Comment 1 Jeff Johnson 2002-08-05 16:15:24 EDT
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 :-(
Comment 2 Ben Harris 2002-08-06 12:34:02 EDT
[ 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".

Comment 3 Ben Harris 2002-08-07 10:51:49 EDT
Created attachment 69284 [details]
Patch to use #! instead of file(1) to detect scripts
Comment 4 Jeff Johnson 2002-08-07 15:55:12 EDT
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 ...
Comment 5 Ben Harris 2002-08-08 10:37:02 EDT
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

Comment 6 Ben Harris 2002-08-08 10:42:05 EDT
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 $?

Comment 7 Jeff Johnson 2002-08-08 10:50:13 EDT
Off to get test(1) (in bash builtin) fixed. Please bounce back to rpm
for further find-requires fixing afterwards.
Comment 8 Bernhard Rosenkraenzer 2002-08-08 11:05:27 EDT
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.
Comment 9 Jeff Johnson 2002-08-12 12:59:24 EDT
So what's the problem with '[' in your bash?
Comment 10 Ben Harris 2002-08-12 13:46:23 EDT
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!

Note You need to log in before you can comment on or make changes to this bug.