What type of parameter/flag can I use with the Unix find
command so that I search executables?
On GNU versions of find you can use -executable
:
find . -type f -executable -print
For BSD versions of find, you can use -perm
with +
and an octal mask:
find . -type f -perm +111 -print
In this context "+" means "any of these bits are set" and 111 is the execute bits.
Note that this is not identical to the -executable
predicate in GNU find. In particular, -executable
tests that the file can be executed by the current user, while -perm +111
just tests if any execute permissions are set.
Older versions of GNU find also support the -perm +111
syntax, but as of 4.5.12 this syntax is no longer supported. Instead, you can use -perm /111
to get this behavior.
Tip of the hat to @gniourf_gniourf for clearing up a fundamental misconception.
This answer attempts to provide an overview of the existing answers and to discuss their subtleties and relative merits as well as to provide background information, especially with respect to portability.
Finding files that are executable can refer to two distinct use cases:
- user-centric: find files that are executable by the current user.
- file-centric: find files that have (one or more) executable permission bits set.
Note that in either scenario it may make sense to use find -L ...
instead of just find ...
in order to also find symlinks to executables.
Note that the simplest file-centric case - looking for executables with the executable permissions bit set for ALL three security principals (user, group, other) - will typically, but not necessarily yield the same results as the user-centric scenario - and it's important to understand the difference.
User-centric (-executable
)
The accepted answer commendably recommends
-executable
, IF GNUfind
is available.- GNU
find
comes with most Linux distros- By contrast, BSD-based platforms, including macOS, come with BSD find, which is less powerful.
- As the scenario demands,
-executable
matches only files the current user can execute (there are edge cases.[1]).
- GNU
The BSD
find
alternative offered by the accepted answer (-perm +111
) answers a different, file-centric question (as the answer itself states).- Using just
-perm
to answer the user-centric question is impossible, because what is needed is to relate the file's user and group identity to the current user's, whereas-perm
can only test the file's permissions.
Using only POSIXfind
features, the question cannot be answered without involving external utilities. Thus, the best
-perm
can do (by itself) is an approximation of-executable
. Perhaps a closer approximation than-perm +111
is-perm -111
, so as to find files that have the executable bit set for ALL security principals (user, group, other) - this strikes me as the typical real-world scenario. As a bonus, it also happens to be POSIX-compliant (usefind -L
to include symlinks, see farther below for an explanation):find . -type f -perm -111 # or: find . -type f -perm -a=x
- Using just
gniourf_gniourf's answer provides a true, portable equivalent of
-executable
, using-exec test -x {} \;
, albeit at the expense of performance.Combining
-exec test -x {} \;
with-perm +111
(i.e., files with at least one executable bit set) may help performance in thatexec
needn't be invoked for every file (the following uses the POSIX-compliant equivalent of BSD find-perm +111
/ GNU find-perm /111
; see farther below for an explanation):find . -type f \( -perm -u=x -o -perm -g=x -o -perm -o=x \) -exec test -x {} \; -print
File-centric (-perm
)
- To answer file-centric questions, it is sufficient to use the POSIX-compliant
-perm
primary (known as a test in GNU find terminology).-perm
allows you to test for any file permissions, not just executability.- Permissions are specified as either octal or symbolic modes. Octal modes are octal numbers (e.g.,
111
), whereas symbolic modes are strings (e.g.,a=x
). - Symbolic modes identify the security principals as
u
(user),g
(group) ando
(other), ora
to refer to all three. Permissions are expressed asx
for executable, for instance, and assigned to principals using operators=
,+
and-
; for a full discussion, including of octal modes, see the POSIX spec for thechmod
utility. - In the context of
find
:- Prefixing a mode with
-
(e.g.,-ug=x
) means: match files that have all the permissions specified (but matching files may have additional permissions). - Having NO prefix (e.g.
755
) means: match files that have this full, exact set of permissions. - Caveat: Both GNU find and BSD find implement an additional, nonstandard prefix with are-ANY-of-the-specified-permission-bits-set logic, but do so with incompatible syntax:
- BSD find:
+
- GNU find:
/
[2]
- BSD find:
- Therefore, avoid these extensions, if your code must be portable.
- Prefixing a mode with
- The examples below demonstrate portable answers to various file-centric questions.
File-centric command examples
Note:
- The following examples are POSIX-compliant, meaning they should work in any POSIX-compatible implementation, including GNU find and BSD find; specifically, this requires:
- NOT using nonstandard mode prefixes
+
or/
. - Using the POSIX forms of the logical-operator primaries:
!
for NOT (GNU find and BSD find also allow-not
); note that\!
is used in the examples so as to protect!
from shell history expansions-a
for AND (GNU find and BSD find also allow-and
)-o
for OR (GNU find and BSD find also allow-or
)
- NOT using nonstandard mode prefixes
- The examples use symbolic modes, because they're easier to read and remember.
- With mode prefix
-
, the=
and+
operators can be used interchangeably (e.g.,-u=x
is equivalent to-u+x
- unless you apply-x
later, but there's no point in doing that). - Use
,
to join partial modes; AND logic is implied; e.g.,-u=x,g=x
means that both the user and the group executable bit must be set. - Modes cannot themselves express negative matching in the sense of "match only if this bit is NOT set"; you must use a separate
-perm
expression with the NOT primary,!
.
- With mode prefix
- Note that find's primaries (such as
-print
, or-perm
; also known as actions and tests in GNU find) are implicitly joined with-a
(logical AND), and that-o
and possibly parentheses (escaped as\(
and\)
for the shell) are needed to implement OR logic. find -L ...
instead of justfind ...
is used in order to also match symlinks to executables-L
instructs find to evaluate the targets of symlinks instead of the symlinks themselves; therefore, without-L
,-type f
would ignore symlinks altogether.
# Match files that have ALL executable bits set - for ALL 3 security
# principals (u (user), g (group), o (others)) and are therefore executable
# by *anyone*.
# This is the typical case, and applies to executables in _system_ locations
# (e.g., /bin) and user-installed executables in _shared_ locations
# (e.g., /usr/local/bin), for instance.
find -L . -type f -perm -a=x # -a=x is the same as -ugo=x
# The POSIX-compliant equivalent of `-perm +111` from the accepted answer:
# Match files that have ANY executable bit set.
# Note the need to group the permission tests using parentheses.
find -L . -type f \( -perm -u=x -o -perm -g=x -o -perm -o=x \)
# A somewhat contrived example to demonstrate the use of a multi-principial
# mode (comma-separated clauses) and negation:
# Match files that have _both_ the user and group executable bit set, while
# also _not_ having the other executable bit set.
find -L . -type f -perm -u=x,g=x \! -perm -o=x
[1] Description of -executable
from man find
as of GNU find 4.4.2:
Matches files which are executable and directories which are searchable (in a file name resolution sense). This takes into account access control lists and other permissions artefacts which the -perm test ignores. This test makes use of the access(2) system call, and so can be fooled by NFS servers which do UID mapping (or root-squashing), since many systems implement access(2) in the client's kernel and so cannot make use of the UID mapping information held on the server. Because this test is based only on the result of the access(2) system call, there is no guarantee that a file for which this test succeeds can actually be executed.
[2] GNU find versions older than 4.5.12 also allowed prefix +
, but this was first deprecated and eventually removed, because combining +
with symbolic modes yields likely yields unexpected results due to being interpreted as an exact permissions mask. If you (a) run on a version before 4.5.12 and (b) restrict yourself to octal modes only, you could get away with using +
with both GNU find and BSD find, but it's not a good idea.
You can use the -executable
test flag:
-executable
Matches files which are executable and directories which are
searchable (in a file name resolution sense).
So as to have another possibility1 to find the files that are executable by the current user:
find . -type f -exec test -x {} \; -print
(the test command here is the one found in PATH, very likely /usr/bin/test
, not the builtin).
1 Only use this if the -executable
flag of find
is not available! this is subtly different from the -perm +111
solution.
This worked for me & thought of sharing...
find ./ -type f -name "*" -not -name "*.o" -exec sh -c '
case "$(head -n 1 "$1")" in
?ELF*) exit 0;;
MZ*) exit 0;;
#!*/ocamlrun*)exit0;;
esac
exit 1
' sh {} \; -print
find . -executable -type f
does not really guarantee that the file is executable it will find files with the execution bit set. If you do
chmod a+x image.jpg
the above find will think image.jpg is an executable even if it is really a jpeg image with the execution bit set.
I generally work around the issue with this:
find . -type f -executable -exec file {} \; | grep -wE "executable|shared object|ELF|script|a\.out|ASCII text"
If you want the find to actually print dome information about executable files you can do something like this:
find . -type f -executable -printf "%i.%D %s %m %U %G %C@ %p" 2>/dev/null |while read LINE
do
NAME=$(awk '{print $NF}' <<< $LINE)
file -b $NAME |grep -qEw "executable|shared object|ELF|script|a\.out|ASCII text" && echo $LINE
done
In the above example the file's full pathname is in the last field and must reflect where you look for it with awk "NAME=$(awk '{print $NF}' <<< $LINE)" if the file name was elsewhere in the find output string you need to replace "NF" with the correct numerical position. If your separator is not space you also need to tell awk what your separator is.
It is SO ridiculous that this is not super-easy... let alone next to impossible. Hands up, I defer to Apple/Spotlight...
mdfind 'kMDItemContentType=public.unix-executable'
At least it works!
Well the easy answer would be: "your executable files are in the directories contained in your PATH variable" but that would not really find your executables and could miss a lot of executables anyway.
I don't know much about mac but I think "mdfind 'kMDItemContentType=public.unix-executable'" might miss stuff like interpreted scripts
If it's ok for you to find files with the executable bits set (regardless of whether they are actually executable) then it's fine to do
find . -type f -perm +111 -print
where supported the "-executable" option will make a further filter looking at acl and other permission artifacts but is technically not much different to "-pemr +111".
Maybe in the future find will support "-magic " and let you look explicitly for files with a specific magic id ... but then you would haveto specify to fine all the executable formats magic id.
I'm unaware of a technically correct easy way out on unix.
I had the same issue, and the answer was in the dmenu source code: the stest utility made for that purpose. You can compile the 'stest.c' and 'arg.h' files and it should work. There is a man page for the usage, that I put there for convenience:
STEST(1) General Commands Manual STEST(1)
NAME
stest - filter a list of files by properties
SYNOPSIS
stest [-abcdefghlpqrsuwx] [-n file] [-o file]
[file...]
DESCRIPTION
stest takes a list of files and filters by the
files' properties, analogous to test(1). Files
which pass all tests are printed to stdout. If no
files are given, stest reads files from stdin.
OPTIONS
-a Test hidden files.
-b Test that files are block specials.
-c Test that files are character specials.
-d Test that files are directories.
-e Test that files exist.
-f Test that files are regular files.
-g Test that files have their set-group-ID
flag set.
-h Test that files are symbolic links.
-l Test the contents of a directory given as
an argument.
-n file
Test that files are newer than file.
-o file
Test that files are older than file.
-p Test that files are named pipes.
-q No files are printed, only the exit status
is returned.
-r Test that files are readable.
-s Test that files are not empty.
-u Test that files have their set-user-ID flag
set.
-v Invert the sense of tests, only failing
files pass.
-w Test that files are writable.
-x Test that files are executable.
EXIT STATUS
0 At least one file passed all tests.
1 No files passed all tests.
2 An error occurred.
SEE ALSO
dmenu(1), test(1)
dmenu-4.6 STEST(1)
So if you actually want to find executable file types (e.g. scripts, ELF binaries etc.. etc..) not merely files with execution permission then you probably want to do something more like this (where the current directory . can be replaced with whatever directory you want):
gfind . -type f -exec bash -c '[[ $(file -b "'{}'") == *" executable "* ]] ' \; -print
Or for those of you who aren't using macports (linux users) or otherwise have gnu find installed as find you want:
find . -type f -exec bash -c '[[ $(file -b "'{}'") == *" executable "* ]] ' \; -print
Though if you are on OS X it comes with a little utility hidden somewhere called is_exec that basically bundles up that little test for you so you can shorten the command line if you find it. But this way is more flexible as you can easily replace the == test with the =~ test and use it to check for more complex properties like executable plain text files or whatever other info your file command returns.
The exact rules for quotation here are pretty opaque so I just end up working it out by trial and error but I'd love to hear the right explanation.
来源:https://stackoverflow.com/questions/4458120/unix-find-search-for-executable-files