there are 2 kinds of patterns
Originally Posted by vasa1
- 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)
ls 'abc*' # literal 'abc*'
ls 'abc'* # anything that matches 'abc'+<whatever>
ls "$var"/* # anything under dir named $var
let's say you have a dir tree with few avi files at top level
find -iname *.avi # will expand glob to find -iname 'file1.avi' 'file2.avi' = error
inside [[ ]] test brackets different rules apply. It's the only place where you can use unquoted variables and get away with it.
find -iname '*.avi' # passes the glob unchanged to find, only there it gets used properly
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.
$ x='abc def'
$ [[ $x =~ 'abc.*' ]] && echo true # didn't work because regex assumed by =~ operator included quotes
$ [[ $x =~ abc.* ]] && echo true
$ [[ $x = 'abc def' ]] && echo true # would fail in [ ] with too many arguments error
yes, besides it's a tool that specializes in processes, why not use that instead of parsing outputs by hand?
Is that because of "The running pgrep or pkill process will never report itself as a match
." (from man pgrep)?