Wyszukaj pliki wykonywalne za pomocą polecenia find

Jakiego typu parametru / flagi mogę używać z findpoleceniem Unix , aby wyszukiwać pliki wykonywalne?

W wersjach GNU find możesz użyć -executable:

find . -type f -executable -print

W przypadku wyszukiwania w wersji BSD można używać -permz +maską ósemkową:

find . -type f -perm +111 -print

W tym kontekście „+” oznacza „którykolwiek z tych bitów jest ustawiony”, a 111 to bity wykonania.

Zauważ, że nie jest to identyczne z -executablepredykatem znajdującym się w GNU find. W szczególności -executabletestuje, czy plik może być wykonany przez bieżącego użytkownika, podczas gdy -perm +111tylko testuje, czy są ustawione uprawnienia do wykonywania.

Starsze wersje GNU find również obsługują -perm +111składnię, ale od 4.5.12 ta składnia nie jest już obsługiwana. Zamiast tego możesz użyć, -perm /111aby uzyskać to zachowanie.

^{Końcówka kapelusza do @Cynk gniourf_gniourf w celu wyjaśnienia fundamentalnego nieporozumienia.}

Ta odpowiedź jest próbą przedstawienia przeglądu istniejących odpowiedzi i omówienia ich subtelności i względnych zalet, a także przedstawienia podstawowych informacji , szczególnie w odniesieniu do przenośności .

Wyszukiwanie plików wykonywalnych może odnosić się do dwóch różnych przypadków użycia :

• zorientowany na użytkownika : znajdź pliki, które są wykonywane przez bieżącego użytkownika .
• file-centric : znajdź pliki, które mają (jeden lub więcej) ustawiony wykonywalnych bitów uprawnień .

Zauważ, że w obu przypadkach sensowne może być użyciefind -L ... zamiast tylko find ...w celu znalezienia dowiązań symbolicznych do plików wykonywalnych .

Zauważ, że najprostszy przypadek dotyczący plików - szukanie plików wykonywalnych z bitem uprawnień do plików wykonywalnych ustawionym dla WSZYSTKICH trzech podmiotów zabezpieczeń (użytkownika, grupy, innych) - zazwyczaj , choć niekoniecznie, daje takie same wyniki, jak scenariusz skoncentrowany na użytkowniku - i ważne, aby zrozumieć różnicę.

Zorientowany na użytkownika (-executable )

• Odpowiedź Zaakceptowany pochlebnie zaleca -executable, JEŚLI GNU find jest dostępna.

  • GNU findjest dostarczane z większością dystrybucji Linuksa
    • Z kolei platformy oparte na BSD, w tym macOS, są wyposażone w funkcję wyszukiwania BSD, która jest mniej wydajna.
  • Zgodnie ze scenariuszem -executabledopasowuje tylko pliki, które może wykonać bieżący użytkownik (istnieją przypadki skrajne. ^[1] ).

• BSD find alternatywa oferowana przez odpowiedź akceptowanego ( -perm +111) odpowiada na inny , plików -centric pytanie (jak sama odpowiedź Zjednoczonych).

  • Używając tylko -permdo odpowiedzi użytkownika -centric pytanie jest niemożliwe , ponieważ to, co potrzebne jest, aby odnosić się w pliku na użytkownika i grupowej tożsamości do bieżącego użytkownika , natomiast-permmoże testować jedyny na plik za uprawnienia.
    Używając tylko funkcji POSIXfind , nie można odpowiedzieć na to pytanie bez zaangażowania zewnętrznych narzędzi.

  • Tak więc najlepiej-perm można zrobić (sam w sobie) jest przybliżenie z -executable. Być może bliższe przybliżenie niż -perm +111jest-perm -111 , aby znaleźć pliki, które mają ustawiony bit wykonywalny dla WSZYSTKICH podmiotów zabezpieczeń (użytkownika, grupy, innych) - wydaje mi się to typowym scenariuszem w świecie rzeczywistym. Jako bonus, zdarza się, że jest również zgodny z POSIX (użyj find -Ldo dołączania dowiązań symbolicznych, wyjaśnienie poniżej):

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

• Odpowiedź gniourf_gniourf dostarcza prawdziwego, przenośnego odpowiednika-executable używania-exec test -x {} \;, choć kosztem wydajności .

  • Łączenie -exec test -x {} \; z -perm +111(tj. Plikami z co najmniej jednym ustawionym bitem wykonywalnego) może pomóc w osiągnięciu wydajności, która execnie musi być wywoływana dla każdego pliku (poniżej użyto zgodnego z POSIX odpowiednika wyszukiwania BSD -perm +111/ GNU find -perm /111; wyjaśnienie znajduje się poniżej) :

    find . -type f \( -perm -u=x -o -perm -g=x -o -perm -o=x \) -exec test -x {} \; -print

Zorientowane na pliki ( -perm)

• Do odpowiedzieć plików -centric pytania , to jest wystarczające, aby korzystać z POSIX -permpodstawowy (znany jako badania w terminologii znaleźć GNU).
  • -permpozwala przetestować dowolne uprawnienia do plików, a nie tylko wykonalność.
  • Uprawnienia są określane w trybie ósemkowym lub symbolicznym . Tryby ósemkowe to liczby ósemkowe (np. 111), Podczas gdy tryby symboliczne to łańcuchy (np a=x.).
  • Tryby symboliczne identyfikują podmioty zabezpieczeń jako u(użytkownik), g(grupa) i o(inne) luba odnoszą się do wszystkich trzech. Uprawnienia są wyrażone xw pliku wykonywalnego, na przykład, a przyporządkowana do zleceniodawcy pomocą operatorów =, +i -; na pełną dyskusję, włącznie z trybami ósemkowym zobaczyć specyfikację POSIX dla chmodużyteczność .
  • W kontekście find:
    • Przedrostek trybu z- (np., -ug=x) Oznacza: dopasowywanie plików, które mają wszystkie uprawnienia określone (ale pasujące pliki mogą mieć dodatkowe uprawnienia).
    • Mający bez prefiksu (np 755) znaczy: pliki meczu, że mają tego pełną, dokładną zestaw uprawnień.
    • Uwaga : zarówno GNU find, jak i BSD find implementują dodatkowy, niestandardowy przedrostek z logiką-ANY-of-the-specified-permission-set-set , ale robią to z niekompatybilną składnią :
      • BSD znajdź: +
      • Znalezienie GNU: / ^[2]
    • Dlatego unikaj tych rozszerzeń, jeśli Twój kod musi być przenośny .
• Poniższe przykłady przedstawiają przenośne odpowiedzi na różne pytania dotyczące plików.

Przykłady poleceń skoncentrowanych na plikach

Uwaga:

• Następujące przykłady są zgodne z POSIX , co oznacza, że ​​powinny działać w każdej implementacji zgodnej z POSIX, włączając wyszukiwanie GNU i BSD; w szczególności wymaga to:
  • NIE używa niestandardowych przedrostków trybu + ani/ .
  • Korzystanie z POSIX-owych form podstawowych operatorów logicznych :
    • !dla NOT (pozwalają również znaleźć GNU i BSD -not); Zwróć uwagę, że \!jest używany w przykładach w celu ochrony! przed ekspansjami historii powłoki
    • -a dla AND (GNU find i BSD find także pozwalają -and )
    • -odla OR (pozwalają również znaleźć GNU i BSD -or)
• W przykładach zastosowano tryby symboliczne , ponieważ są one łatwiejsze do odczytania i zapamiętania.
  • Z przedrostkiem trybu -, operatory =i +mogą być używane zamiennie (np. -u=xJest równoważne -u+x- chyba że zastosujesz -xpóźniej, ale nie ma to sensu).
  • Służy ,do łączenia trybów częściowych; Logika AND jest implikowana; np. -u=x,g=xoznacza, że musi być ustawiony zarówno bit wykonywalny użytkownika, jak i grupa.
  • Tryby same w sobie nie mogą wyrażać negatywnego dopasowania w sensie „dopasuj tylko wtedy, gdy ten bit NIE jest ustawiony”; należy użyć osobnego -permwyrażenia z NOT podstawowym, !.
• Należy pamiętać, że znalezienie w prawyborach (takie jak -print, lub -perm; znany również jako działań i badań w GNU znaleźć) są domyślnie połączone z -a(logiczne AND), a że -oi ewentualnie nawiasów (uciekły jak \(i\) dla powłoki) są potrzebne do wdrożenia lub logiczny.
• find -L ...zamiast just find ...służy do dopasowywania dowiązań symbolicznych do plików wykonywalnych
  • -Linstruuje find, aby oceniać cele dowiązań symbolicznych zamiast samych dowiązań symbolicznych; Dlatego bez -L, -type fcałkowicie zignorowałoby dowiązania symboliczne.

# 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] Opis stanu -executablez man findGNU znaleźć 4.4.2:}

Dopasowuje pliki, które są wykonywalne i katalogi, które można przeszukiwać (w sensie rozpoznawania nazw plików). Uwzględnia to listy kontroli dostępu i inne artefakty uprawnień, które test -perm ignoruje. Ten test wykorzystuje wywołanie systemowe access (2), więc może zostać oszukany przez serwery NFS, które wykonują mapowanie UID (lub wycinanie rootów), ponieważ wiele systemów implementuje dostęp (2) w jądrze klienta i nie może korzystać z informacje o odwzorowaniu UID przechowywane na serwerze. Ponieważ ten test jest oparty tylko na wyniku wywołania systemowego access (2), nie ma gwarancji, że plik, dla którego ten test się powiedzie, będzie mógł rzeczywiście zostać wykonany.

^{[2] GNU find wersje starsze niż 4.5.12 również dopuszczały prefiks +, ale najpierw został on uznany za przestarzały i ostatecznie usunięty, ponieważ łączenie +z trybami symbolicznymi daje prawdopodobnie nieoczekiwane rezultaty, ponieważ jest interpretowane jako dokładna maska ​​uprawnień. Jeśli ty (a) prowadzony w wersji przed 4.5.12 i (b) nie ogranicza się do ósemkowe trybów tylko, to mógłby uciec z korzystaniem +z obu GNU znaleźć i BSD znaleźć, ale nie jest to dobry pomysł.}

Aby mieć inną możliwość ¹ znalezienia plików, które są wykonywalne przez bieżącego użytkownika:

find . -type f -exec test -x {} \; -print

(tutaj polecenie test jest tym, które można znaleźć w PATH, najprawdopodobniej /usr/bin/testnie wbudowanym).

¹ Używaj tego tylko wtedy, gdy -executableflaga findnie jest dostępna! różni się to nieco od -perm +111rozwiązania.

Możesz użyć -executableflagi testowej:

-executable
              Matches files which are executable  and  directories  which  are
              searchable  (in  a file name resolution sense).

To zadziałało dla mnie i pomyślałem o udostępnieniu ...

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

tak naprawdę nie gwarantuje, że plik jest wykonywalny, znajdzie pliki z ustawionym bitem wykonania. Jeśli zrobisz

chmod a+x image.jpg

powyższe find uzna, że ​​image.jpg jest plikiem wykonywalnym, nawet jeśli jest to naprawdę obraz jpeg z ustawionym bitem wykonywania.

Generalnie omijam ten problem z tym:

find . -type f -executable -exec file {} \; | grep -wE "executable|shared object|ELF|script|a\.out|ASCII text"

Jeśli chcesz, aby znalezisko faktycznie wyświetlało informacje o plikach wykonywalnych, możesz zrobić coś takiego:

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

W powyższym przykładzie pełna ścieżka dostępu do pliku znajduje się w ostatnim polu i musi odzwierciedlać, gdzie go szukasz za pomocą awk "NAZWA = $ (awk '{print $ NF}' <<< $ LINE)", jeśli nazwa pliku była gdzie indziej w znaleziony ciąg wyjściowy, który należy zastąpić „NF” poprawną pozycją numeryczną. Jeśli twoim separatorem nie jest spacja, musisz także powiedzieć awk, jaki jest twój separator.

To jest TAK śmieszne, że nie jest to super łatwe ... nie mówiąc już prawie niemożliwe . Ręce do góry, odsyłam do Apple / Spotlight ...

mdfind 'kMDItemContentType=public.unix-executable'

Przynajmniej działa!

Cóż, prostą odpowiedzią byłoby: „Twoje pliki wykonywalne znajdują się w katalogach zawartych w zmiennej PATH”, ale tak naprawdę nie znalazłoby to twoich plików wykonywalnych i mogłoby i tak pominąć wiele plików wykonywalnych.

Nie wiem zbyt wiele o Macu, ale myślę, że "mdfind 'kMDItemContentType = public.unix-executable'" może pomijać takie rzeczy, jak interpretowane skrypty

Jeśli możesz znaleźć pliki z ustawionymi bitami wykonywalnymi (niezależnie od tego, czy są one faktycznie wykonywalne), to dobrze jest to zrobić

find . -type f -perm +111 -print

jeśli jest obsługiwana, opcja „-executable” utworzy kolejny filtr sprawdzający acl i inne artefakty uprawnień, ale technicznie niewiele różni się od „-pemr +111”.

Być może w przyszłości program find będzie obsługiwał "-magic" i pozwoli ci bezpośrednio szukać plików z określonym magicznym identyfikatorem ... ale wtedy musiałbyś określić, aby wszystkie wykonywalne formaty były poprawne.

Nie jestem świadomy technicznie poprawnego, łatwego wyjścia z Uniksa.

Więc jeśli naprawdę chcesz znaleźć pliki wykonywalne (np. Skrypty, pliki binarne ELF itp. Itd.), A nie tylko pliki z uprawnieniami do wykonywania , prawdopodobnie chcesz zrobić coś więcej podobnego (gdzie bieżący katalog można zastąpić jakimkolwiek katalog, który chcesz):

 gfind . -type f -exec bash -c '[[ $(file -b "'{}'") == *" executable "* ]] ' \; -print

Lub dla tych z Was, którzy nie używają macports (użytkownicy Linuksa) lub w inny sposób mają zainstalowany GNU Find, tak jak chcecie:

 find . -type f -exec bash -c '[[ $(file -b "'{}'") == *" executable "* ]] ' \; -print

Chociaż jeśli korzystasz z systemu OS X, jest dostarczane z małym narzędziem ukrytym gdzieś o nazwie is_exec, które zasadniczo zawiera ten mały test, dzięki czemu możesz skrócić wiersz poleceń, jeśli go znajdziesz. Ale ten sposób jest bardziej elastyczny, ponieważ możesz łatwo zamienić == test na = ~ test i użyć go do sprawdzenia bardziej złożonych właściwości, takich jak wykonywalne pliki tekstowe lub jakiekolwiek inne informacje zwracane przez polecenie pliku.

Dokładne zasady cytowania są tutaj dość niejasne, więc po prostu pracuję nad tym metodą prób i błędów, ale chciałbym usłyszeć właściwe wyjaśnienie.

Miałem ten sam problem, a odpowiedź znajdowała się w kodzie źródłowym dmenu : najlepsze narzędzie stworzone do tego celu. Możesz skompilować pliki „stest.c” i „arg.h” i powinno działać. Jest strona podręcznika użytkownika, którą umieściłem dla wygody:

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)