Dotaz: podivne spravanie Bash

[zatkowich]

Zdravim,

popis mojho problemu je jednoduchy. Mam nedavno nainstalovane OpenSuse 13.1 na 2PC. Neviem vysvetlit nasledovne:

Na obidvoch PC prikaz

ps aux | kded

ma spravny vystup, napr.

blizzard  4863  0.0  0.0  10520   924 pts/2    S+   23:02   0:00 grep --color=auto kded

.

Na 1 PC vsak po pridani dalsieho grep, napr. prikazom

ps aux | grep kded | grep kdeinit

je vystup prazdny, na druhom spravny.

Nie som (zatial? :) ) tak hlboko v Linuxovych systemoch, aby som vedel, kde vobec zacat tento problem riesit. Dotazy do sudruha Gooogela v style "double pipe not working" apod. nenasli asi nic relevantne, resp. nepodarilo sa mi najst podobny problem, preto prosim o pomoc tu.

Odpovědi

[majales]

Nějak jsem nepochopil co má být výstupem. Součástí toho výstupu co jsi poslal není řetězec kdeinit. To co jsi našel je podle mě jen ten samotný příkaz co hledá kded - protože tam je "grep --color=auto kded". Takže ta odpověď je vlastně irelevantní.

To co by skutečně ten příkaz s dvojitým grepem měl dělat je vybrat z procesů ty které obsahují řetězec "kded" - to pro první grep, a pak ten výstup prohnat druhým grepem který v něk hledá kdeintit. Čili pokud tam není proces který má v COMMANDu řetězec "kded" a zároveň "kdeinit" tak to nikdy nic nenajde a pokud to něco najde tak to neodpovídá tomu co jsi chtěl skutečně najít.

[FrostyX]

Jaké vlastnosti má mít ten vrácený řádek?

Pokud má obsahovat řetězec "kded" a "kdeinit" současně, pak jsi ten příkaz napsal správně, jen takový řádek v ps aux prostě není.

Pokud má obsahovat buď "kded" nebo "kdeinit", pak můžeš zkusit

ps aux |grep -E "kded|kdeinit"

[Šangala]

Příště napiš:

ps aux | grep k[d]ed

a problém, který neexistuje, nebude ani vidět.

[zatkowich]

Ospravedlnujem sa za minanie Vasho casu, pisal som to v neskoru hodinu nevyspaty. Chyba bola samozrejme v tom, ze som nemal spusteny proces, ktory by v prikaze obsahoval obidva hladane stringy, co som bral ako samozrejmost... Totizto pred reinstalom systemu mi to fungovalo, a to z nasledovneho dovodu:

Ide o skript na restart KDE, ktory som pouzival kvoli memory leaku kded4 asi tak 1x za den (s KDE iny vaznejsi problem nemam). Tentokrat sa mi vsak zjavne kded4 niekedy spusti bez kdeinit4 (co uplne nechapem) a z toho vznikla tato situacia, problem je teda vyrieseny (prinajhorsom login-logoff) alebo vobec neexistuje :)

Dakujem za odpovede, cosi som sa znova naucil.

[Šangala]

Je třeba myslet na to, že pokud grepuješ příkaz typu ps (prohledáváš procesy), můžeš a často zachytíš sám sem tedy ten proces, kterým prohledáváš. Pokud nahradíš:

ps -ef | grep nejakytext

za

ps -ef | grep n[e]jakytext

tak už si nezachytíš sám sebe, protože hranaté závorky znamenají výčet povolených znaků a pokud je mezi nimi jen jeden znak, tak je to pro grep jako by tam nebyly, ale v procesech jsou vidět i ty závorky, což neodpovídá hledanému textu, takže najdeš opravdu jen to co jsi hledal a ne sám sebe.

[Michal Kubeček]

Místo podobných triků bych spíš doporučil

  ps -fC name

protože na rozdíl od grepování výstupu udělá to, co tazatel (s největší pravděpodobností) opravdu chce. Tedy najde instance určitého programu, ne všechno, co má name jako substring jména nebo parametru.

[Šangala]

Pravděpodobně v tomto konkrétním případě ano, ale obecně lze hledat i něco jiného nebo přesnějšího (včetně parametrů) a přijde mi snazší to grep-nout rovnou, než tam dávat -C program a pak znovu grep, nebo třeba (fčil jsem použil):

ps -ef | grep -e 'socket://192\.168\.[0-9]\{1,3\}\.[0-9]\{1,3\}:9100' | sed …

[Michal Kubeček]

Problém je v tom, že málokdo si dá práci, aby ten regulární výraz napsal pořádně, což se dá tolerovat při interaktivní práci, kde je chyba hned poznat, ale bohužel to až příliš často vídám i ve skriptech.