Re: What does "grep "something" > /dev/null" do?

/dev/null is a pseudodevice that acts as a garbage bin. Redirect there as if you redirected to a file, the difference being there will be no trace of output anywhere
That said, the redirection was not necessary as grep has -q option that suppresses its output

as for bracketed first char. In comments below he explains it's there to avoid grep finding itself in case of ps aux | grep program.
grep will show up as 'grep program' on the list of processes and will find itself and you will get something like this

Re: What does "grep "something" > /dev/null" do?

Originally Posted by Vaphell

/dev/null is a pseudodevice that acts as a garbage bin. Redirect there as if you redirected to a file, the difference being there will be no trace of output anywhere
That said, the redirection was not necessary as grep has -q option that suppresses its output
...[/code]

Okay, so in grep's specific case we can use -q but otherwise can use > /dev/null.

Originally Posted by Vaphell

as for bracketed first char. ... because [b]ash regex doesn't match '[b]ash' string

Yet another type of regex! From here, it appears that the rules change with bash updates!
BTW, this link also says that "we highly recommend you just never quote your regex". Is that why the string wasn't between double quotes? So we should just do

Code:

grep -options string

and not

Code:

grep -options "string"

Originally Posted by Vaphell

that said, pgrep is a better tool for that

Is that because of "The running pgrep or pkill process will never report itself as a match." (from man pgrep)?

Re: What does "grep "something" > /dev/null" do?

Originally Posted by vasa1

Okay, so in grep's specific case we can use -q but otherwise can use > /dev/null.

Yet another type of regex! From here, it appears that the rules change with bash updates!
BTW, this link also says that "we highly recommend you just never quote your regex". Is that why the string wasn't between double quotes? So we should just do

Code:

grep -options string

and not

Code:

grep -options "string"

there are 2 kinds of patterns
- shell globs: eg [abc]*, used in shells to match files
- regular expressions: eg [abc].*, used to match text in grep, sed, awk, you name it + bash [[ ]]

in case of bash globs you don't want to quote it too much, because quoted wildcards like * lose their magic

in case of globs used with find -name you need to quote them to prevent upacking the expression before find runs ( shell: step1 - expand parameters and globs, step2 - run command with the results)
let's say you have a dir tree with few avi files at top level

Any other case of using regexes falls under standard rules and you want to always wrap them, preferably in single quotes to avoid surprises, because yet again shell would try to expand the parameter and if there is a matching file, grep would get things other than what you intended.

Is that because of "The running pgrep or pkill process will never report itself as a match." (from man pgrep)?

yes, besides it's a tool that specializes in processes, why not use that instead of parsing outputs by hand?

Re: What does "grep "something" > /dev/null" do?

there are 2 kinds of patterns
- shell globs: eg [abc]*, used in shells to match files
- regular expressions: eg [abc].*, used to match text in grep, sed, awk, you name it + bash [[ ]]

in case of bash globs you don't want to quote it too much, because quoted wildcards like * lose their magic ...

in case of globs used with find -name you need to quote them to prevent upacking the expression before find runs ( shell: step1 - expand parameters and globs, step2 - run command with the results) ...
...
inside [[ ]] test brackets different rules apply. It's the only place where you can use unquoted variables and get away with it.
...
Any other case of using regexes falls under standard rules and you want to always wrap them, preferably in single quotes to avoid surprises, because yet again shell would try to expand the parameter and if there is a matching file, grep would get things other than what you intended.
...

I've saved this post for future reference. I came across globbing first when using Privoxy's user.action file for making blocking rules. I'm not sure I fully grasped the subtleties involved but went ahead by trial-and-error and looking at Privoxy's logs.Find also gave me quite a bit of grief but I'll give it another go with the knowledge I gained here. But I'm going to make another post about