Finding executable files in linux

Searching for executable files

Is there a way to search and delete all executables files within folder if there is no extension? e.g Let’s suppose I have 4 files with .ubu extension and the following bash does the job I’m asking for:

e.g_2 Now let’s suppose I have 4 but there is no extension at all, something like: test test_2 test_3 ( chmod +x on them) How do I delete those files?

3 Answers 3

If we’re talking about files with executable bit set, then find command has -executable test, and a -delete action.

find /DIR/EC/TORY -type f -executable -delete 

find /DIR/EC/TORY -type f -executable -exec rm -f <> \; 

To specifically delete all executable files in your home directory (not in sub-directories) and ask you whether you want to delete each file you can do something like

find ~ -type f -executable -maxdepth 0 -exec rm -i <> \; 

 -exec command ; Execute command; true if 0 status is returned. All following arguments to find are taken to be arguments to the command until an argument consisting of `;' is encountered. The string `<>' is replaced by the current file name being processed everywhere it occurs in the arguments to the command, not just in arguments where it is alone, as in some versions of find. Both of these constructions might need to be escaped (with a `\') or quoted to protect them from expansion by the shell. See the EXAMPLES sec‐ tion for examples of the use of the -exec option. The specified command is run once for each matched file. The command is exe‐ cuted in the starting directory. There are unavoidable secu‐ rity problems surrounding use of the -exec action; you should use the -execdir option instead. -exec command <> + This variant of the -exec action runs the specified command on the selected files, but the command line is built by appending each selected file name at the end; the total number of invoca‐ tions of the command will be much less than the number of matched files. The command line is built in much the same way that xargs builds its command lines. Only one instance of `<>' is allowed within the command. The command is executed in the starting directory. 

Источник

Search for executable files using find command

Not all implementations of find are created equal. The option recommended by @sje397 and @William may not be available. It’s better to use the accepted solution shown below.

Me dislikes all proposals shown below which are based on file permissions. Argumentation: for my GNU operating system (Ubuntu) it is possible to set «x» (executable) flag for for instance ASCII text file. No mimics prevented this operation from successful completion. It needs just small mistake/bug for multiple non-intentioned files to get x flag assigned. Therefore gniourf_gniourf’ solutions is my personal favorite. It has however that drawback that for cross-compiled executables needs an emulator or target device.

10 Answers 10

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.

@sourcejedi Thanks. I was actually only talking about non-GNU versions of find (BSD, in particular) but older versions of GNU find actually did support that syntax too. In newer versions you’ll have to use / instead of + . See the updated answer for more details.

It took me a while to understand the implications of «not identical to the -executable predicate» and «just tests if any execute permissions are set»: It means that -perm +111 may yield false positives, i.e., files that the current user cannot actually execute. There’s no way to emulate -executable by testing permissions alone, because what’s needed is to relate the file’s user and group identity to the current user’s.

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 GNU find is available.
  • GNU find comes with most Linux distros
    • By contrast, BSD-based platforms, including macOS, come with BSD find, which is less powerful.

    find . -type f -perm -111 # or: find . -type f -perm -a=x 

    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 issufficient 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) and o (other), or a to refer to all three. Permissions are expressed as x for executable, for instance, and assigned to principals using operators = , + and — ; for a full discussion, including of octal modes, see the POSIX spec for the chmod 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]

          File-centric command examples

          • 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 )
              • 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, ! .
              • -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.

              Источник