Wyszukaj pliki wykonywalne za pomocą polecenia find


113

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


wpisz „znajdź człowieka”. Myślę, że „-executable” to opcja, której potrzebujesz.
sje397

3
find -executable... ale to nie gwarantuje, że każdy wymieniony plik faktycznie zostanie wykonany
William,

1
Nie wszystkie implementacje findsą sobie równe. Opcja zalecana przez @ sje397 i @William może nie być dostępna. Lepiej skorzystać z zaakceptowanego rozwiązania pokazanego poniżej.
LS


Nie podoba mi się wszystkie propozycje przedstawione poniżej oparte na uprawnieniach do plików. Argumentacja: dla mojego systemu operacyjnego GNU (Ubuntu) można ustawić flagę "x" (plik wykonywalny) na przykład plik tekstowy ASCII. Żadne mimiki nie uniemożliwiły pomyślnego zakończenia tej operacji. Potrzebuje tylko małego błędu / błędu dla wielu niezamierzonych plików, aby uzyskać przypisaną flagę x. Dlatego rozwiązania gniourf_gniourf są moim ulubionym. Ma jednak tę wadę, że dla skompilowanych krzyżowo plików wykonywalnych wymaga emulatora lub urządzenia docelowego.
Na13-c

Odpowiedzi:


173

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.


Błąd find: invalid mode ‘+111’w findutils 4.5.11 4.fc20.
sourcejedi,

1
@sourcejedi Thanks. Właściwie mówiłem tylko o wersjach find (w szczególności BSD) innych niż GNU, ale starsze wersje GNU find faktycznie obsługiwały również tę składnię. W nowszych wersjach będziesz musiał użyć /zamiast +. Więcej informacji można znaleźć w zaktualizowanej odpowiedzi.
Laurence Gonsalves,

Rzeczywiście, źle odczytałem twoją odpowiedź. Przepraszam, że to bardziej skomplikowane :).
sourcejedi

Jeśli dowiązania należy również do plików wykonywalnych, obejmują -Lopcję: find -L ....
mklement0

Zajęło mi trochę czasu, zanim zrozumiałem implikacje „nie identyczne z predykatem -executable” i „tylko testy, jeśli jakieś uprawnienia do wykonywania są ustawione”: Oznacza to, że -perm +111może to powodować fałszywe alarmy , tj. Pliki, których aktualny użytkownik nie może faktycznie wykonać. Nie ma sposobu, aby emulować -executablepoprzez testowanie uprawnienia sama, bo to, co potrzebne jest, aby odnosić się w pliku na użytkownika i grupowej tożsamości do bieżącego użytkownika .
mklement0

35

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ł.


2
Najbardziej wszechstronna odpowiedź SO kiedykolwiek? ;)
andynormancx

@andynormancx :) Cóż, jeśli chodzi o samą liczbę wypunktowanych punktów, mogę zaoferować tego kandydata .
mklement0

11

Aby mieć inną możliwość 1 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).


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


2
To działa, ale działa dość wolno. Ponadto, w zależności od powłoki, może być konieczne zawinięcie lub uniknięcie symbolu zastępczego nazwy pliku, takiego jak '{}'lub \{\}.
Ionoclast Brigham

1
@ mklement0 to nie znajdzie poleceń, które są wykonywane przeze mnie, tak jak -executablerobi lub tak jak robi moje polecenie.
gniourf_gniourf

1
Dzięki, @gniourf_gniourf - naprawdę miałem kilka nieporozumień. Ponownie drukuję tutaj twój drugi komentarz, ponieważ przynajmniej na razie usuwam swoją odpowiedź (być może w celu wskrzeszenia, JEŚLI jest coś do odzyskania): „ niefind . -type f -perm -u=x jest odpowiednikiem : dopasowuje wszystkie pliki, które użytkownik może wykonać, a te obejmują jeśli jestem w odpowiedniej grupie lub . W rzeczywistości znajdę wiele plików, których użytkownik nie może wykonać, i przegapię kilka, które użytkownik może wykonać. " -executable-executableg+xo+x-perm -u=x
mklement0

1
@IonoclastBrigham: Chociaż cytowanie {}jest hipotetyczną koniecznością (a cytowanie nie boli), w praktyce nie jest to konieczne w powłokach podobnych do POSIX i csh. Czy znasz muszle, gdzie jest to wymagane?
mklement0

4
@IonoclastBrigham: Interesujące, dzięki; tak więc w fish, {}rzeczywiście musi zostać uciec jako albo '{}'albo \{\}. Zauważ, że bash, kshi zshzapewnij ten sam rodzaj rozwijania nawiasów; jednak drukują niezacytowany token taki, {} jaki jest (a zatem: nie ma potrzeby ucieczki), ponieważ NIE uważają go za prawidłowe wyrażenie nawiasu (wymagają co najmniej 2 tokenów lub prawidłowego wyrażenia sekwencji liczbowej), podczas gdy fish uznają {}za prawidłowy nawias klamrowy wyrażenie, którego wynikiem jest pusty ciąg.
mklement0

9

Możesz użyć -executableflagi testowej:

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

4
-executable jest podobno nieznaną opcją.
cóż, właściwie

4
Czy byłoby to rozszerzenie GNU Find? Ponieważ znacznikiem jest Unix, a nie Linux, przynajmniej rozszerzenie GNU musi być udokumentowane jako takie.
Jonathan Leffler

3
Ta opcja nie jest obsługiwana przez polecenie find BSD, które można znaleźć przynajmniej w systemie OS X. Jest to rozszerzenie GNU, ale może być obsługiwane przez inne odmiany wyszukiwania.
Ionoclast Brigham

FWIW, okazało się, że to nie jest na slesach 10, ale na sles> = 11 (trochę się przez to spaliło)
Peter Turner

Zwróć uwagę, że to faktycznie nie obejmuje wszystkich przykładów. W moim przypadku miałem plik, który posiadałem jako -rw-r-xr-xktóry -executablenie wykrywa
Dezza

2

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

13
Tylko kilka tysięcy przypadków więcej, a będziesz odkrywać na nowo file!
tripleee

@tripleee +1. Fajne byłoby to rozszerzenie:find ./ -mime application/x-sharedlib -o -mime application/x-dosexec
Daniel Alder

@Daniel Alder, której wersji Find używasz? Nie znalazłem opcji -mime w find (GNU findutils) 4.4.2
AjayKumarBasuthkar

@tripleee +1. użycie 'file' i / 'mimetype' jest dobrym pomysłem lub znajdź wersję, która obsługuje -mime jest lepsza. Zastanawiasz się również, czy 'file' / 'mimetype' ma opcję filtrowania i wyświetlania tylko plików wykonywalnych.
AjayKumarBasuthkar

2
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.


1

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!


Dobrze wiedzieć o mdfindOSX. Zauważ, że polecenie uour raportuje pliki wykonywalne Uniksa dla całego systemu . mdfind -onlyin . 'kMDItemContentType=public.unix-executable'ogranicza wyniki do poddrzewa bieżącego katalogu. Drobne interesujące miejsca: ograniczenie wyszukiwania tylko do określonego katalogu (bez podfolderów) najwyraźniej nie jest obsługiwane. Najwyraźniej odnośniki symboliczne do plików wykonywalnych nie są dołączane. Co ciekawe, po mdfindznalezieniu pliku jako wykonywalnego, późniejsze usunięcie tego bitu wykonywalnego nie jest odbierane.
mklement0

Myślę, że znalazłem błędy w sposobie, w jaki Spotlight wykrywa / niewykrywa wykonywalne pliki Unix; Zgłosiłem błąd w Apple, a także na openradar.me/20162683 . Zachęcam was - i ktoś zainteresowany tą funkcjonalność - również zgłosić błąd w błąd w bugreport.apple.com
mklement0

(Przepraszam za zamieszanie w komentarzach; mam nadzieję, że teraz mają rację) mdfind -onlyin . 'kMDItemContentType=public.unix-executable'zachowuje się jak find . -type f -perm +111 -printrobi. Oznacza to, że znajduje pliki z dowolnym ustawionym bitem wykonywalnym, co może dawać fałszywe alarmy (chociaż w praktyce może to nie być problemem) - aby naprawdę znaleźć tylko pliki wykonywalne przez bieżącego użytkownika za pomocą funkcji wyszukiwania BSD, zobacz odpowiedź @ gniourf_gniourf. Korzystanie z findrozwiązania opartego na rozwiązaniach ma tę zaletę, że w razie potrzeby można znaleźć dowiązania symboliczne do plików wykonywalnych (opcja -L), czego mdfindpozornie nie można zrobić.
mklement0

1
@ mklement0 moja odpowiedź uniknęła upiększeń - aby spróbować uciszyć sedno sprawy - ale tak, prawie nigdy nie używałbyś tego formularza „bez ozdób”. inna opcja - nie jestem pewien, czy się pojawi - jest stara dobra, globalna .. ls /Applications/**/*(*)w twojej (mojej?) zshpowłoce
Alex Gray

Dzięki za przydatną zshwskazówkę - nie wiedziałem tego; (Wydaje się, że można też dopasować wykonywalne ( *) lub dowiązania ( @), ale nie oba, prawda?). Jeśli chodzi o twój pierwotny punkt: powtórzę: find . -type f -perm +a=xzrobi to, co robi twoje mdfindpolecenie, zapewniając jednocześnie większą elastyczność. Możesz nawet przeformułować go tak, aby był zgodny z POSIX.
mklement0

1

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.


1

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.


0

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)
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.