bash regexp file vegzodesre.

Szkriptek: Python, Perl, Bash, ...

Biztos volt mar tema, de most futottam bele es kernek tanacsokat :)
Konkretan, az /etc/postfix/db osszes NEM .db vegzodesu filera szeretnem a psotmap parancsot lefuttatni. (gondot nem okoz, ha az osszes fileon fut, csak most mar hajt a kivancsisag)

Szoal, ami mukodik: (most csak ls)
ls *[^.db]
Vmiert (nem jottem ra, miert ) a
ls *[^.db]$ viszont nem...pedig ez elvileg a sor veget nezne.
Nagyobb gond, hogy a karakterek elofordulasat nezi, szoval a fentinel latszik a "dbfile" (hiszen nincs a vegen *), de nem latszik a "filebd" , hiszen a fenti regexpben csak az van megadva, hoyg barmi az elejen, utana "d" vagy "b" vagy ".", felteve, hogy jol ertem es a "bd" tartalmazza a "d" es "b" karaktereket.

szoval hogyan lehetne altalanossagban, hoyg bizonyos vegzodest szurjek (ne csak a karakterek, hanem a sorrendjuk is szamit?)

  • 9328 megtekintés

( turdus | 2012. 07. 04., sze – 11:45 )

Ez hibás regexp. A csillag önmagában nem jelent semmit, mivel az őt megelőző kifejezést ismétli x-szer (beleértve a nulla előfordulást is). Azaz mást jelent, mint hiszed, nem azt, hogy "bármi az elején". Ezen kívül a [^.db] illeszkedik minden karakterre (pont miatt), amit negálsz, azaz semmire nem fog ugrani. A helyes [^\.][^d][^b]$, mivel egy pozíción csak egy karaktered van (n-2. egy pont, n-1. "d", n. "b", ahol n a név hossza), míg a [^\.db] azt jelenti, hogy az adott pozíción nem állhat pont, "d" vagy "b" karakter, ami megint nem azt jelenti, mint amit szeretnél.

Koszi, csillagot tudtam. Jelen esetben azt jelenti, hoyg "barmi az elejen". Mondjuk, akkor inkabb "^*" , de mindegy (ez is zavaro, a hatvanyozas jel ketfele jelentese: regexp eleje vagy negalas)

Hopp, felfogtam a masodik reszet is. Mert nekem ugyesen adott talalatokat es tenyleg furcsa volt, hogy a "." miatt miert ad...Logikus: az elotte levo csillag miatt lehet barmi, az utolso karakter meg ne legyen d, b es barmi (egy karakter). Hmm, megsem logikus, az utolso karakter nem letezhet...

Namindegy, koszi! Szoval [] reszekre kell bontani...eszembe juthatott volna :(

--
http://www.micros~1

A csillagot rosszul tudtad. Azt jelenti, hogy az előtte levő karakter, vagy csoport nullaszor, vagy többször kell szerepeljen.
pl.: az "a*" regex matchel az alábbi sztringekre:
bela
aaaalma
aa
aaa

nem matchel az alábbiakra:
teszt
medve

Amire te gondolhattál az a ".*" kifejezés. Tetszőleges karakterből (a reguláris kifejezésben . jelzi) nulla, vagy akár végtelen sok előfordulás. De ha egy $ van a regexp végén, akkor az elejére nem szabad ^.* -ot tenni, mert felesleges teljesítménycsökkenést okozol vele.

> a [^.db] illeszkedik minden karakterre (pont miatt), amit negálsz, azaz semmire nem fog ugrani.

Két apróság:

- szögletes zárójelek között a . nem speciális karakter, nem kell takarni, és nem jelenti a bármit.
- a shell (normális esetben) nem regexpet használ, hanem egy ahhoz látszólag nagyon hasonló valamit, így a regexpres tudás (még ha jó tudás is) nem nagyon segít.

( krumplicska | 2012. 07. 04., sze – 12:30 )

Figyu, ami a shellben van az nem regexp :) úgy hívják pattern matching :) csak hasonlóan néznek ki, de tök más.

olvasd el a sh manuált Pattern Matching résznél.

Good luck.

( uzsolt v | 2012. 07. 04., sze – 12:42 )

Baromi egyszerű: 


$ shopt -s extglob
$ ls
alma  korte  szilva.db
$ ls !(*.db)
alma  korte

( egeresz | 2012. 07. 04., sze – 12:45 )

bash (shell) nem csinal regexp-et.

Regexpet a grep, awk, sed, parl (etc) csinal. Amit a shell csinal, az valami olyasmi, de nem regexp. (regular expression: regurális nyelvet leíró kifejezés).

Amit a shell csinál, az 'wildcard matching' -nak szokás nevezni, a bash manja 'pathname expansion' -nak hív, ami kombinálható a 'brace expansion' -nal.

Pathname expansion speciális karakterei:
*
?
[
ez jóval kevesebb annál, mint amit a regexp nyujt.

Azonban a bashnak vannak kiterjesztései, amivel a minta illesztés feloksítható, lásd:
shopt -s extglob
ls *.gz # minden .gz -re vegzodo file
ls !(*.gz) # miden file, ami nem illeszkedik a *.gz mintara

A programfejlesztésnél valamennyire szempont, hogy azt másvalaki később megértse, továbbfejleszteni tudja, vagy esetleg megtalálja benne a hibát. Előfordul, hogy az a másvalaki pont te vagy 2 év mulva. Ennek érdekében illik nélkülözni a nyelv által megengedett, de a nyelvhasználók közösségében nem használt formulákat, pl C:
alma["alma"]

vagy éppen bash -ban a nem-default opciók használata, vagy akár csak a
mv alma{,.txt}

Az a helyzet, hogy a 'ls !(*.db)' helyett sokkal érthetőbb a 'find -not -name *.db' sőt, még sokkal érthetőbb a 'find | grep -v "\.db$" '.
Az ennél bonyolultabb formulákhoz olyan nyelvet kell keresni, ahol ez szokásos (tehát a programozók köztudatában benne van). A bonyolult regexp formulák használatának szokásos nyelve a perl.

azert lassuk be, hogy ezeket a cuccokat legtobben azert nem hasznaljak, mert nem ismerik
miert jo az neked, hogy find + grepet inditgatsz, amikor a bash alapbol tudja ?
ha vki ilyen nem szabvany cuccot lat, az nezze meg a mant
a findnak, grepnek is van egy csomo valtozata, az mennyivel jobb, hogy arra epitesz ?
raadasul ez csak egy parsoros valami, nem egy ezersoros szkript
szerintem nyugodtan lehet mindenfele kiterjesztest hasznalni, kulonben mi ertelme lenne az egesznek ?

miert jo az neked, hogy find + grepet inditgatsz, amikor a bash alapbol tudja ?

Mutass egy példát BASH-ben légy szíves, ami listaként visszaadja a nem ".db"-re végződő fájlokat. Értem én, hogy a teszt operátort [[ =~ ]] használod, de ez máshogy működik.
Például az echo * parancsot beírva a BASH a * helyére behelyettesíti neked az aktuális könyvtárban levő fájlok/folderek listáját. Az általad említett regexes matchelés csak úgy alkalmas erre, ha egy lista elemein végig iterálsz, és az összes elemre egy if [[ =~ ]]-et hívsz meg. Ez valóban megoldható egy sorban is, de szerintem sokkal olvashatatlanabb, mint egy find, vagy egy ls+grep kombó. Ha valami nem olvasható könnyen, akkor - ahogy azt egeresz kolléga is írta - problémákat okozhat az utólagos módosítás.

Egy problémát, vagy megoldandó feladatot több szempontot figyelembe véve kell mérlegelni:
* Mennyi idő van rá?
* Mennyire kell az tartós megoldás legyen? (Ha csak egy quick and dirty fix, akkor például nem cél, hogy a kód optimális legyen, és talán még az olvashatóság sem annyira fontos)
* Utólagos fejlesztés lesz-e?
(egyéb szempontot most nem látok lényegesnek, de javítsatok ki)

Figyelembe véve a fenti három szempontot olyan megoldást adtam, ami tipikus quick and dirty fix, mivel:
1. Rövid
2. Egy átlagos, shell programozást némileg ismerő informatikusnak könnyedén érthető, vagyis: olvasható
3. Ugyan nem a leghatékonyabb, de a megoldásom nem képezi részét egy nagyobb rendszernek, tehát megengedhettem magamnak ezt a luxust.
4. Nem kellett sokat agyalni rajta -> hamar elkészültem vele.

Igaz, ami igaz, a find-os megoldás még az enyémnél is olvashatóbb egy, a reguláris kifejezéseket nem ismerő informatikusnak. Az olvashatóság nagyon-nagyon fontos, ideje lenne leszokni a ki tud értelmezhetetlenebb kódot írni versengésről. Ilyen kódot szinte bárki tud írni hasra ütéssel, de az olyan is lesz.

ha vki ilyen nem szabvany cuccot lat, az nezze meg a mant

Véleményem szerint ez meglehetősen önző, szűklátókörű és legfőképpen nem emberközpontú hozzáállás, ami sok informatikusra jellemző. Miért ne lehetne olyan elegáns megoldást adni, amihez NEM FELTÉTLENÜL KELL man-t olvasni?

a findnak, grepnek is van egy csomo valtozata, az mennyivel jobb, hogy arra epitesz ?

Ahogy a BASH-nek is, amiben szintén változhat a reguláris kifejezések szintaktikája.

mert az ls + grep kombod nem azt csinalja, hogy lelistazod a konyvtartartalmat, aztan szursz, ugye ?

ebben mi az olvashatatlan ?
for i in * ; do [[ $i =~ db$ ]] || echo $i ; done

minek van a bash tudasa, ha senki sem hasznalja, mert gondolni kell arra is, aki csak kicsit ismeri.

egyebkent foleg azert irtam, mert kijelentettek h bashban nincs regexp

jaa, es a findnak, grepnek lsnek mindenki fejbol tudja a manjat ?

Ezt a kérdést, mármint hogy minek van a bash tudása már mintha láttam volna. Csak akkor kb. úgy volt megfogalmazva, hogy mifasznak, mivel a funkciók mondjuk felét havonta egyszer használják.

Az másik kérdés, hogy ha van egy képessége a shellnek, akkor használjam-e. Ha indokolt (pl. sebesség), akkor persze. De csak azért, mert tudja, nem fogom használni.

És igen, a grep, find, ls jobban ismert, de már csak a man hosszából adódóan is (a man bash nálam bő 5000 sor, míg a man grep nincs 700), de mint nemrég kiderült, ezeket se árt átolvasni ám néha.

Amúgy - bár ennek nincs jelentősége - a fenti példába még kell egy \. is ("osszes NEM .db vegzodesu").

Plusz gyorsan csináltam kb. 50k fájlt, itt már az ls+grep kb. 3-4x gyorsabb mint a tisztán bash megoldás. Persze ha mind .db-re végződött volna akkor lehet hogy más lenne az eredmény, de most lusta vagyok azt is kimérni.

nem mondtam, hogy csak ezt kell hasznalni, de ha mar benne van a bashban, akkor hasznalhato, nem kell tiltani mindent ami az sh kompatibilitason felul benne van.
kulonben mi ertelme van az egesznek?
nehogy mar ugy kelljen szkriptet irni, hogy azon gorcsoljek milyen ember fogja 3 ev mulva megnezni.
ki hatarozza meg, mi az elvarhato szint, amit figyelembe kell venni ?
ahol ez elvaras, ott jelezni fogjak.

szerintem messze az extglobos megoldas a legjobb, es gyors is, nem tudom miert kellett lehuzni
ez csak egy kb 10 masodperces feladat, miert kell 20 sort irni arrol, mi a helyes hozzaallas az egy soros szkript kesobbi
karbantartojahoz.

pl ha hasznalom a bash /dev/tcp-t, most akkor tegyek le rola, mert alig lattam egy-ket helyen ?

Pl. azért - és szégyellem, hogy ezt csak most vettem észre - hogy az echo * visszaadja a könyvtárakat is, így kb. muszáj a find-et használni, ha csak a fájlokra van szükség. Persze lehetne greppelni a könyvtárakat, de az már tényleg csúf.

És ha a /dev/ptc használata az ideális megoldás, akkor azt kell használni. Csakhát az ideális megoldás megfogalmazása szokott problémás lenni :D

nehogy mar ugy kelljen szkriptet irni, hogy azon gorcsoljek milyen ember fogja 3 ev mulva megnezni.

Nyilván azért gondolod így, mert nem vagy fejlesztő. De legalább is jó fejlesztő nem lehetsz.
De ha ilyen kis szkriptekben gondolkodsz, amiket csak magadnak írsz, arra ez a felfogás is teljesen elegendő. Én már jártam úgy, hogy egy éve fejlesztett Perl szkriptet akartam kiegészíteni, de az lett a vége, hogy újra kellett írnom. Mindezt azért, mert akkoriban még nem tudtam, hogyan kell olvasható kódot írni. Bátran kijelenthető, hogy az alkalmazott nyelvtől függetlenül érdemes olvasható kódot írni.

ez csak egy kb 10 masodperces feladat, miert kell 20 sort irni arrol, mi a helyes hozzaallas az egy soros szkript kesobbi
karbantartojahoz.

Kelleni nem kell, csak azért írtam, hogy tanulj. :) Saját tapasztalatból mondom, hogy tetszőleges fejlesztési feladat esetén sokat segíthet pár egyszerű elv betartása még akkor is, ha nem vagy fejlesztő.

Szerintem a globstar-os megoldás teljesen jól olvasható és érthető. Ha ilyet akarok használni, nem fogok közvéleménykutatást tartani, hogy ki az, aki ismeri és ki az, aki nem. Én ismerem, én tudom használni, én tudom értelmezni.
Ha csapatban dolgozik az ember, nyilván vannak megkötések és szabályok és konvenciók, de nehogy már az echo !(*.db) annyira olvashatatlan legyen, főleg egy pár soros szkriptben (akinek mégis, tanuljon meg olvasni)...

Ja, és mi van abban az esetben, ha esetleg 3 év múlva ez annyira elterjedt lesz, hogy kiszorítja (háttérbe szorírja) a find/grep-es megoldást? Akkor csak sz@r lett a most elterjedtebb find/grep megoldás, mert 100 emberből érti 80 a globstar-t, 60 a find/grep-et, a maradék 40 meg bújhatja a mant.

Kód olvashatósága: egy beszúrt megjegyzés sokat szokott érni a későbbiekben.

"Én már jártam úgy, hogy egy éve fejlesztett Perl szkriptet akartam kiegészíteni, de az lett a vége, hogy újra kellett írnom. Mindezt azért, mert akkoriban még nem tudtam, hogyan kell olvasható kódot írni."
Tehát akkor te se voltál jó fejlesztő :) Ja, és honnan tudod, hogy a kódod most olvasható? Egy év múlva érteni fogod? Gondolom, a perl-szkriptre is így gondoltál egy éve :)

Tehát akkor te se voltál jó fejlesztő :) Ja, és honnan tudod, hogy a kódod most olvasható? Egy év múlva érteni fogod? Gondolom, a perl-szkriptre is így gondoltál egy éve :)
Így van, nem voltam az, ezt nem is tagadom. Mindenki elkezdi valahol. Onnan tudom, hogy betartok néhány agilis szoftverfejlesztési elvet. Ezeket vagy a kollégáimtól, vagy a Robert C. Martin-féle Tiszta kód című könyvből tanultam. Ennek nem az a célja, hogy egy év múlva is emlékezz a kódra. Hanem az, hogy ha ránézel, könnyen (rövid idő alatt) fel tudd eleveníteni annak működését. Nem tartom magamat különösen jó fejlesztőnek (de azért szarnak semmiképpen sem), ugyanakkor csola-val szemben én képes vagyok a fejlődésre. Vicces a másfél-két évnél régebbi kódjaimat olvasni, éps látni, hogy milyen szarok (noha működnek). Veled talán nem fordult ilyen elő?

Ami a Perl szkriptes meglátásodat illeti: nem fogalmaztam elég érthetően. A kérdéses szkriptet 2006-ban írtam, és valamikor 2007-ben kellett újraírnom. A két időpont között kb. egy év telt el.

Kód olvashatósága: egy beszúrt megjegyzés sokat szokott érni a későbbiekben.
A Martin C. Fowler könyv szerint többek között akkor olvasható egy kód, ha úgy van megírva, hogy:
* a változónevek beszédesek
* nincsenek kommentek, mivel
* a kód kellőképpen kifejező

Lehet persze ezekkel az érvekkel vitatkozni, egyet nem érteni, de nekem szimpatikusak. Persze nem kőbe vésett szabály, és olykor-olykor egy-egy kommentet kiteszek én is.

Vannak azért olyan helyzetek, amikor a kód (algoritmus) annyira kacifántos, hogy kell egy-két megjegyzés a kódba, hogy értsd (legalábbis könnyebben vagy hamarabb). Nem arra gondolok, hogy egy ciklus miért 100-tól kétszázig megy, hanem ha egy összetettebb algoritmusra, aminek pl. kemény matematikai háttere van vagy esetleg egy-két kivételes esetet le kell kezelni, azért kell plusz 5 sor - később nem biztos, hogy eszedbe jut, hogy az az öt sor (amit feleslegesnek tartasz) azért került oda, mert előfordulhat egy-két kivételes eset.

Es emiatt lehet ritkan hasznalt megoldasokat is hasznalni. Legfeljebb kommentben odairom, hogy bekapcsolja a regexp alapu pattern matchinget, es akkor barki, aki utanam jon, tudni fogja, mi ez, vagy legalabbis utanaolvas.

A kommenteles nem az ordogtol valo am.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

koszi, majd pont te fogod eldonteni milyen fejleszto vagyok.
egyedul fejlesztek, tehat engem ilyen szempontok nem erdekelnek
nem hiszem hogy pont rad kene hallgatnom, ezzel a hozzaallassal nem feltetelezem, hogy melyen ismered a basht, plane a perlt.
a perl pl tipikusan az a nyelv, amin lehet elvezkedni, miert ne tennem ?
nem hiszem hogy toled kene tanulnom, koszi, mogottem is van 13 ev perl programozas, ja es meg veletlenul sem mondanam, hogy minden
idiota megoldast ismerek, de en legalabb torekszem ra, mert elvezem is.

te meg nyugodtan irkalj meg ilyeneket bashban, hogy if test x$a = xy, stb...

koszi, majd pont te fogod eldonteni milyen fejleszto vagyok.
Talán kicsit erősen fogalmaztam. Kiegészítés: szerintem.

egyedul fejlesztek, tehat engem ilyen szempontok nem erdekelnek
Hát persze, hogy nem érdekelnek. De ha netán valakinek át kellene vennie tőled valamelyik (vagy az összes projekted) kódját, akkor az illető mennyire gyorsan tudná megérteni a kódot, amit írtál? Ez az érdektelenség szerintem gáz.

nem hiszem hogy toled kene tanulnom, koszi, mogottem is van 13 ev perl programozas, ja es meg veletlenul sem mondanam, hogy minden
A fejlesztési elveket sajnos nem tanítják együtt a programozási nyelvekkel. Ezt sajnálatosnak tartom. Perlben nyilván nem tudnék neked újat mondani, mert nincs ennyi tapasztalatom benne.

idiota megoldast ismerek, de en legalabb torekszem ra, mert elvezem is.
???
Törekszel az idióta megoldásra? Gratulálok. :)

te meg nyugodtan irkalj meg ilyeneket bashban, hogy if test x$a = xy, stb...
Mondtam már: attól függ, hogy ki a célközönség. Ha csak egy gyors és egyszerű megoldás kell, akkor akár a tied is használható lehet. De tegyük hozzá, hogy minél egyszerűbb valami, annál kevesebb hibalehetőség van benne. És az egyszerű nem feltétlenül jelenti a rövidet.

Hát persze, hogy nem érdekelnek. De ha netán valakinek át kellene vennie tőled valamelyik (vagy az összes projekted) kódját, akkor az illető mennyire gyorsan tudná megérteni a kódot, amit írtál? Ez az érdektelenség szerintem gáz.

tudom hogy senki sem fogja atvenni, egyszeruen ilyen helyzetben vagyok

Törekszel az idióta megoldásra? Gratulálok. :)
a perl mar csak ilyen, tele van idiota megoldasokkal, van aki ruhelli, en nem

ha megmondjak hogy irjam a progit, akkor tartom (tartanam) magam hozza, kulonben miert ne csinalhatnek azt amit akarok ?
min is vitatkozunk ?

" De ha netán valakinek át kellene vennie tőled valamelyik (vagy az összes projekted) kódját, akkor az illető mennyire gyorsan tudná megérteni a kódot, amit írtál?"
Egy hasonloan kepzett perl fejleszto szerintem egy het alatt. Te? Hat nem tudom, meddig tart midnent ujrairni :-)
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

meg annyit, hogy a szkriptiras pillanataban, hacsak nincs ra valami policy, akkor az iroja a fonok, hadd hasznalja mar ki
a teljes eszkoztarat, majd eldonti mi a jo neki.
nem obfuscated kodot kell irni, de nehogy mar egy shopt v egy regexp problema legyen.
Azert van szakmai onerzet is a vilagon.
Az olvashatosag pedig relativ, minel profibb valaki, annal konnyebben olvas nehezebb kodot.
ha alap kodot irsz, abbol csak az derul ki, hogy minimum alap szinten ismered a nyelvet.

Nezd, ha a scriptben beallitom az extglobot vagy a globstar-t, akkor legalabbis gyanusnak kell legyen barkinek, hogy ez mi a francot keres ott. Es akkor elolvassa a manualt.

Szerintem pont attol lesz valakibol jo programozo, hogy nem fel dokumentaciot olvasni. Nagyon jo programozo akkor lesz valakibol, ha beismeri, hogy nem tud/nem ert dolgokat.

En is irtam mar at kodot azert, mert gozom nem volt, mit akartam oda irni, mikor expressz sebesseggel kellett megoldast talani vmi problemara.
De olyan meg sose volt, hogy hasznaltam volna egy megoldast, amire ket ev utan nem emlekeztem, es emiatt kidobtam volna a komplett scriptet. Nekiultem, atolvastam a doksi megfelelo reszet, es tudtam.

Ennyi erovel meg mindig lehetne bash 2, ha epp mindig csak annyi funkcionalitast hasznalunk, ami csak abban volt. Teljesen felesleges fejleszteni a shell-t.

Abban igazad van, hogy sokat tud segiteni bizonyos elvek betartasa a konnyebb karbantartasban. De ezek koze nem biztos, hogy oda tartozik a feature-kkel valo sporolas.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

en jelentettem ki, es igazad van, a 'bashban nincs regexp' nem fedi a valosagot. az adott kontextusban beleertettem, de nem irtam ki, hogy 'pathname expansion'.

Más. Szeretem és használom a bash olyan funkcióit, hogy <<< vagy read -d'\0' -r; ezek olyan funkciók, amik a tisztességes munkához nem nélkülözhetők. Azonban pl határozottan félek az 'echo *' jellegű megoldásoktól, beláthatatlan (és konkrét környezet-függő) hibákat lehet vele elérni.

kiprobaltam es nalam mukodik
a b c\n nevu fileokra is
50000 masikra
nem a leggyorsabb, de bash only megoldasnak elmegy
egyebkent ha az echot kicsereled a megfelelo parancsra, es nem lista kell, akkor sporolsz egy xargsot is sok filenel
persze lehet akar pl find -regex ... -exec ... {} +
sok megoldas van

A * kibontásával szokott galiba adódni, ha túl sok (hosszú a parancssor), no meg a szóközt tartalmazó fájlnevek feldolgozásával, hiszen a "lista" az jelen esetben egy vagy több whitespace-szel elválasztott karaktersorozatok sorozata, azaz például a 


echo $( for i in * ; do echo $i ; done) | while read a; do ls -l $a; done

prímán mutatja, hogy a "for i in *..." a szóközt/whitespace-t tartalmazó fájlnevek esetén nem azt adja vissza, amit te szeretnél.
Ha már GNUism, akkor esetleg a find -print0 kapcsolója jöhet számításba.

a for i in *, helyes listat ad, max utana a listafeldolgozsnal lehet gaz

echo $(for i in * ; do [[ ! $i =~ \.db$ && -f $i ]] && echo "'$i'" ; done)
'a b c' 'a b cc '

ha az echot kicsereled a megfelelo parancsra es nem listat akarsz, akkor eleve jo, ha listat akarsz, akkor $i idezofelek koze

neked a fentiben az echo/read kavar be, nem a for i in *
ha csak az irod h echo "'$i'", latod hogy jo

Nem. Ugyanis a * kifejtését a shell csinálja, és utána az így összeállt parancssort hajtja végre, ha "belefér". Ha nem, akkor nem.
A for i in $( find ...) ; do ... satöbbi, vagy a find ... | csinalj_a_stdin-en_kapott_nevu_fajlokkal valamit esetén lehet akármekkora a find kimenetének a mérete, csak blokkolódni fog a find a cső telerottyantása után - de ahogy ürül a cső, megy tovább.

Jól írod az xargs-t, viszont a for i in * esetén pont ellene beszélsz azzal, hogy limit nélkül kéred a shellt a behelyettesítésre és a parancssor feldagasztására :-)
A bash (GNU bash, version 4.1.10(4)-release (i686-pc-cygwin)) megeszi az 512k-nál nagyobb méretűre * behelyettesítést (ls | wc -c nagyobb, mint 524288), nagyobb mérettel nem próbálkoztam, más shell esetén viszont rejtélyes hibát tud okozni a "mohó" behelyettesítés.

en nem kevernem ide a pipe-ot, mindegyik megoldas listarol szol, igy kertek
az egy tok mas helyzet

probald ki:
getconf ARG_MAX:
262144

for i in * nem akad le 100000 filenal
ls * viszont: argument list too long

tehat all, amit mondtam, for i * visszaadhat joval nagyobb listat, mint amit fel lehet dolgozni, ezert kellhet xargs
nem egyforma a limit

( uid_2716 | 2012. 07. 05., cs – 01:10 )

Megoldható globbing-gal, de nem szép, és ha el akarjuk kerülni a hibaüzeneteket a találat nélküli glob pattern-ek miatt, akkor a nullglob shopt-ra szükség lesz.

Ez a minta: 

? ?? *[!.]?? *.[!d]? *.d[!b]

Az egy karakter hosszú filenevek nyilván nem végződnek ".db"-vel. A kettő hosszúak szintén nem.

Ha legalább három karakter hosszú a filenév, akkor az utolsó három közül legalább egynek el kell térnie a minta adott pozíciójától. 

suffix[0] != '.' || suffix[1] != 'd' || suffix[2] != 'b'

Ezt írja le az utolsó három minta, biztosítva azt is, hogy azok a file-nevek, amelyekben több pozíción is fennáll a kívánt eltérés, csak egyszer fognak szerepelni (félig-meddig a fenti C kifejezésben a || operátor rövidzár jellegére hajazva).

( Celtic v | 2012. 07. 05., cs – 08:17 )

Uristen, nem hittem, hogy ilyen gyonyoru vitat generalok egy egyszeru kerdessel. En ugy tudtam, hogy regexp = regular expression, vagyis szabvanyos kifejezes. Hivhatjuk ezt mintaillesztesnek is, a Buki-konyvbol indultam ki. De azt hiszem, ez a legkevesbe fontos ebben.

Ahogy fentebb emlitettem, a "*" jelentesevel tisztaban vagyok, a post-ban azert irtam, hogy "mindenre illeszkedik", mert jelen esetben igy van. Csak kapkodtam (munkaido, nem ez volt a legfontosabb, cska felmerult bennem) es azert nem azt irtam, hoyg "az elotte levo n. darab (akar nulla) ismetlodesere illeszkedik". Na.

Hiaba, ez a HUP 2012-ben.

--
http://www.micros~1

Azért a dolog nem ilyen egyszerű. globbing (ez a shell dolga) esetén az ab* azt jelenti, hogy kell legyen a, ezt követi b, majd állhat mögötte más (c, d, e, stb). regexp esetén ellenben ugyanez az ab* minta azt jelenti, hogy kell legyen a, ezt pedig tetszőleges darabszámú (akár nulla is) b kell hogy kövesse, de csak a b jó, semmilyen másik karakter nem megengedett.

És hát erről megy itt feljebb a vita.

Ez persze igy nem igaz. Kovetheti az a-t c is, hiszen a b akar nullaszor is elofordulhat. Es mivel nem konkretizaltuk, hogy a kifejezes teljes szoveges-e (vagyis automatikusan beleertendo a ^ es a $), igy a default a nem teljes szoveges kereses. :-)
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Akkor pontositsunk. Maga a megadott minta fog illeszkedni c-re egyik vagy masik esetben (glob vs regexp)? Nem az a kerdes, hogy megtalaljuk-e a sort/filenevet, hanem hogy amit a "minta" megtalal, abban lesz-e c vagy nem. Mert en errol beszelek.

(Aki regexpet tanul, annak kicsit sokaig szokott tartani megerteni az "illeszkedik 0 hosszusagban" illetve a "nem-illeszkedik" kozti kulonbseget, holott nagyon nem mindegy. Pl. egy felteteles kereses-csere jo pelda ra.)

Az attol fugg, mivel keresed a mintat.

Az echo 'ac' | egrep 'ab*' - barmily meglepo - illeszkedni fog, espedig azert, mert a regexp eseteben ketfele illesztest kulonboztetunk meg: amikor a megadott mintanak az egesz stringre (sorra) illeszkednie kell, es amikor a minta a string egy reszere illeszkedik. Az elso esetnel ugye implicite feltetelezzuk, hogy a minta ^-el kezdodik es $-el zarodik, akkor is, ha ez explicite nincs kiirva a mintaban. Ez esetben igazad van, az 'ac' nem illeszkedik az 'ab*' mintara, hiszen az 'a' es 'b'-n kivul mas nem elfogadott.

Amennyiben azonban a megadott mintat literalisan tekintjuk (vagyis nem elunk a ^/$ megletenek premisszajaval) abban az esetben az 'ac' illeszkedhet az 'ab*' mintara, hiszen csak azt mondjuk, hogy a keresett szovegben szerepeljen egy 'a' betu, es nulla vagy tobb 'b' betu. Ezen kitetelt pedig az 'ac' teljesiti, az utolso betuig, ugyanis 1 darab 'a' es nulla darab 'b' betu van benne, a minta ezt koveteli meg.

Globbing eseteben nyilvan nem fog illeszkedni, hiszen a globbingban megadott 'ab*' az valojaban egy 'ab.*' regularis kifejezesnek felel meg, amire az 'ac' minta meg csak veletlenul sem illeszkedik. Ezzel nem is volt soha gondom.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Jogos. Most mar elviselheto ido van, a neuronjaim is visszaalltak normal mukodesre.

"egyesek abba is kepesek belekotni, hogyha porkoltet eszel tesztaval, akkor kanallal vagy villaval"

Asszem, igy helyesebb. Bar, meg mindig tobb vesszot hasznalok, mint egy atlag angol :)
--
http://www.micros~1