Изпечатай

[freedj]

Здравейте

Търся програма или може би код с който мога да пусна проверка, на всички дялове на една Linux машина за проверка на .exe файлове. Целта ми е ако намери нещо да ми покаже пътя до него.

Благодаря ви kostov

[romeo_ninov]

Здравейте

Търся програма или може би код с който мога да пусна проверка, на всички дялове на една Linux машина за проверка на .exe файлове. Целта ми е ако намери нещо да ми покаже пътя до него.

Благодаря ви kostov

Ех, няма ли кой да научи основите на Линукс/UNIX?

Код:

find / -name "*.exe"

[laskov]

Ако пък смяташ, че ехе-тата може да са маскирани под друго име, програмата
file име_на_файл ти казва какъв е типа на файла.

[freedj]

Благодаря ви но аз се оправих със следната команда:

Код:

locate  -e .exe > file.txt

Така лиснах, всички ехе-та в файл на име file.txt

[romeo_ninov]

Благодаря ви но аз се оправих със следната команда:

Код:

locate  -e .exe > file.txt

Така лиснах, всички ехе-та в файл на име file.txt

За втори път: "Ех, няма ли кой да научи основите на Линукс/UNIX?"

малък цитат от ман страницата на командата locate:

By default, locate does not check whether files found in database still exist; locate can never report files created after the most recent update of the relevant database.

[b2l]

За втори път: "Ех, няма ли кой да научи основите на Линукс/UNIX?"

За ко не го оставиш да си чупи главата. Тъкмо следващата "умна" тема, ще е "Locale ми показва път до файл, който вече го няма".
Ти нали му написа:

Код:

find / -name *.exe

[borovaka]

Абе пак става с locate ако пуска updatedb предварително. Ама зависи какво е нужно в ситуацията, щото веднъж като се индексира базата на locate после търсенето е много по-бързо от при find.

[romeo_ninov]

Абе пак става с locate ако пуска updatedb предварително. Ама зависи какво е нужно в ситуацията, щото веднъж като се индексира базата на locate после търсенето е много по-бързо от при find.

Да, вярно е, но ако искаш картина в реално време, locate не е инструмента. Освен това колко хора пускат updatedb в крона си?

[gat3way]

Ако наистина искаш картина в реално време, и find не е начина. Особено при големи файлови системи - просто отнема много време. Единственият начин е да се драсне нещо, което ползва inotify. Има известни ограничения, но може да се направи. Едно време бях хванал да си пиша демонче, което да следи и да изтрива качени PHP "шелове" в момента, в който бъдат качени. Отказах се, защото това създава повече проблеми, отколкото решава - изключително лесно е да DoS-неш машината така (форкваше се нов процес за всеки такъв файл, който или затриваше файла, или го вкарваше в карантина). Има начини тези проблеми да се избегнат, ама ме домързя да се занимавам. После, търсенето за зловреден код по pattern-и е кауза пердута.

[neter]

Абе пак става с locate ако пуска updatedb предварително. Ама зависи какво е нужно в ситуацията, щото веднъж като се индексира базата на locate после търсенето е много по-бързо от при find.

Да, вярно е, но ако искаш картина в реално време, locate не е инструмента. Освен това колко хора пускат updatedb в крона си?

Всъщност, няма нищо лошо в предварителното изпълнение на updatedb от задача в cron-а. Базата данни, която updatedb създава и обновява, е много добре индексирана, така че веднъж създадена, тази база данни се актуализира много бързо при следващо извикване на updatedb. В повечето случаи при достатъчно често викане на updatedb, актуализирането на базата отнема части от секундата до няколко секунди. Като се вземе предвид и бързото изкарване на резултатите от locate, то схемата updatedb->locate винаги е много по-бърза и много по-лека от find. Всъщност, практически няма възможност за пускането на find на всяка минута от cron-а, тъй като той винаги обхожда цялата файлова система, заради липсата на индекси, и това е тежък и времеемък процес, като единствено има забързване на find, ако се застъпи в изпълнението си с друг find (което при изпълнение на всяка минута със сигурност ще се случи, и няма да се застъпват само по два find-а), понеже резултатите от find временно застават в RAM-та и застъпилите го други find-ове могат да ползват тези резултати при изпълнението си, но системата ще продължава константно да е натоварена от постоянно изпълняващи се find-ове, които минават през всички файлове. Докато схемата updatedb->locate съвсем спокойно може да се пуска от cron на всяка минута, без това да тежи на системата и без да се застъпват. Самата скорост на изпълнение на updatedb->locate при вече създадена база може да предложи много по-бързо намиране на нови файлове, отколкото find

[romeo_ninov]

..... Докато схемата updatedb->locate съвсем спокойно може да се пуска от cron на всяка минута, без това да тежи на системата и без да се застъпват. Самата скорост на изпълнение на updatedb->locate при вече създадена база може да предложи много по-бързо намиране на нови файлове, отколкото find

Да, с малката уговорка че с find мога междувременно да свърша доста други неща (в една команда).
П.П. А застъпването на find-отве, особено ако вършат нещо конкретно никога не е водило до добро

[neter]

Да, с малката уговорка че с find мога междувременно да свърша доста други неща (в една команда).

Така е, но в самата си основа тази една команда, в която едновременно се вършат и други неща, не се различава много от тази, приличаща на една команда

Код

GeSHi (Bash):
updatedb && locate 'нещо' | while read i; do rm $i; done

където допълнителните действия са заключени между "do" и "done", могат да бъдат наистина всякакви, и броят им не е ограничен по никакъв начин (за уточнение, на който му е нужно, в примера изтривам намерените резултати).
На практика, с появата на алгоритми като locate, алгоритмите като find са ограничили реалната си полза до това да участват в попълването на базите данни на алгоритми като locate. За потребителя няма реално преимущество да ползва алгоритми като find, освен ако не е тръгнал да създава собствени бази данни на ниско ниво.

[romeo_ninov]

Да, с малката уговорка че с find мога междувременно да свърша доста други неща (в една команда).

Така е, но в самата си основа тази една команда, в която едновременно се вършат и други неща, не се различава много от тази, приличаща на една команда

Код

GeSHi (Bash):
updatedb && locate 'нещо' | while read i; do rm $i; done

където допълнителните действия са заключени между "do" и "done", могат да бъдат наистина всякакви, и броят им не е ограничен по никакъв начин (за уточнение, на който му е нужно, в примера изтривам намерените резултати).
На практика, с появата на алгоритми като locate, алгоритмите като find са ограничили реалната си полза до това да участват в попълването на базите данни на алгоритми като locate. За потребителя няма реално преимущество да ползва алгоритми като find, освен ако не е тръгнал да създава собствени бази данни на ниско ниво.

Това въобще не е вярно, нещо не мярнах в locate възможност да търся на определена дълбочина, определен тип файлове, време на създаване, на последен достъп и много, много други. Това че рядко се използват не означава че в определени моменти няма да се получи така че да са незаменими и да спестят много допълнителна работа
Ако става въпрос за просто търсене на имена на файлове - да, но ако се иска малко по-фино филтриране - не

[neter]

Това въобще не е вярно, нещо не мярнах в locate възможност да търся на определена дълбочина, определен тип файлове, време на създаване, на последен достъп и много, много други.

А какво ти пречи между "do" и "done" да вмъкнеш каквито си искаш филтрации? Целта на locate е да ти даде бързо файловете, а пък ти можеш да си правиш каквото искаш с тях в цикъла, и пак ще е с пъти по-бързо и по-леко от find. Не гледай само командата locate, а и цикъла, вързан към нея в по-горния пример. За филтрациите по начална папка, дълбочина и тип на файловете добавяш регулярен израз с grep, който може да седи както вътре в цикъла, така и преди него, в цикъла можеш да си листнеш атрибутите на файловете и да провериш съдържа ли се даден атрибут с дадена стойност, и т.н., и т.н., всичко, което може да му хрумне на човек.
Съгласен съм, че скриптът, изписан с find, ще е няколко символа по-къс от този с locate, но кого в практическите задачи го интересува дали скриптът ще е с няколко байта по-голям или по-малък? А с locate получаваш с пъти по-бързо и по-леко изпълнение, а това вече е важно. Дай ми реална ситуация, в която locate не може да се използва, и find се оказва незаменим. Аз се сещам само за една - когато в средата липсват инструментите, нужни на locate за дадената задача. Е, това вече би било спънка за locate, но е толкова спънка, колкото и за find да не са инсталирани findutils например, или find да е компилиран с окастрени алгоритми. Забрави това, че при търсене с locate не може да се направи дадено нещо с резултатите, това не е вярно. При търсене с find също може да се направи всичко с резултатите - когато свършат вградените неща във find, пак ще се прибегне до допълнителните инструменти на средата, както се прави с locate. Така че, какво може и какво не може при двете търсения не е критерий за сравнение на методите. Ето ги реалните преимущества на всеки метод:
- при търсене с find - няколко байта по-къс код;
- при търсене с locate - с пъти по-бързо и по-леко изпълнение.

[romeo_ninov]

Това въобще не е вярно, нещо не мярнах в locate възможност да търся на определена дълбочина, определен тип файлове, време на създаване, на последен достъп и много, много други.

...
- при търсене с find - няколко байта по-къс код;
- при търсене с locate - с пъти по-бързо и по-леко изпълнение.

1. помисли колко сложно може да се окаже търсене/филтриране на файлове от определена стартова точка на определена дълбочина с грепове и други филтри и колко просто става в find
2. страхувам се че find винаги ще е доста по-къс при по-сложни филтрирания, защото прави филтрирането вътрешно и няма нужда да е извикват външни програми за целта
3. същото важи за скоростта защото доколкото знам филтрирането на find е част от процеса на търсенето и става вътрешно т.е. се избягва целия процес на предаване на информацията към шел и от там към външна програма
4. Не знам за вас, но ОС с които се занимавам включват Solaris, HP-UX и това автоматично предопределя какво да ползвам