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
Code:
ls 'abc*' # literal 'abc*'
ls 'abc'* # anything that matches 'abc'+<whatever>
ls "$var"/* # anything under dir named $var
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
Code:
find -iname *.avi # will expand glob to find -iname 'file1.avi' 'file2.avi' = error
Code:
find -iname '*.avi' # passes the glob unchanged to find, only there it gets used properly
inside [[ ]] test brackets different rules apply. It's the only place where you can use unquoted variables and get away with it.
Code:
$ x='abc def'
$ [[ $x =~ 'abc.*' ]] && echo true # didn't work because regex assumed by =~ operator included quotes
$ [[ $x =~ abc.* ]] && echo true
true
$ [[ $x = 'abc def' ]] && echo true # would fail in [ ] with too many arguments error
true
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?
Bookmarks