grep pattern single and double quotes - grep

Is there any difference between enclosing grep patterns in single and double quotes?
grep "abc" file.txt
and
grep 'abc' file.txt
I'm asking since there's no way I could test all possible cases on my own, and I don't want to stumble into a case that I get wrong :)

I see a difference if you have special characters :
Ex :
grep "foo$barbase" file.txt
The shell will try to expand the variable $barbase, this is maybe not what you intended to do.
If instead you type
grep 'foo$barbase' file.txt
$bar is taken literally.
Finally, always prefer single quotes by default, it's stronger.

In double quote, the following characters has special meanings: ‘$’,
‘`’, ‘\’, and, when history expansion is enabled, ‘!’.
The characters ‘$’ and ‘’ retain their special meaning within double
quotes ($ for variables and for executing).
The special parameters ‘*’ and ‘#’ retain their special meaning in
double quotes as inputs when proceeded by $.
‘$’, ‘`’, ‘"’, ‘\’, or newline can be escaped by preceding them with
a backslash.
The backslash retains its special meaning when followed by ‘$’, ‘`’,
‘"’, ‘\’, or newline. Backslashes preceding characters without a
special meaning are left unmodified.
Also it will be helpful to check shell expansions:
https://www.gnu.org/software/bash/manual/html_node/Shell-Expansions.html#Shell-Expansions
Single quote ignore shell expansions.

Related

select only a word that is part of colon

I have a text file using markup language (similar to wikipedia articles)
cat test.txt
This is a sample text having: colon in the text. and there is more [[in single or double: brackets]]. I need to select the first word only.
and second line with no [brackets] colon in it.
I need to select the word "having:" only because that is part of regular text. I tried
grep -v '[*:*]' test.txt
This will correctly avoid the tags, but does not select the expected word.
The square brackets specify a character class, so your regular expression looks for any occurrence of one of the characters * or : (or *, but we said that already, didn't we?)
grep has the option -o to only print the matching text, so something lie
grep -ow '[^[:space:]]*:[^[:space:]]*' file.txt
would extract any text with a colon in it, surrounded by zero or more non-whitespace characters on each side. The -w option adds the condition that the match needs to be between word boundaries.
However, if you want to restrict in which context you want to match the text, you will probably need to switch to a more capable tool than plain grep. For example, you could use sed to preprocess each line to remove any bracketed text, and then look for matches in the remaining text.
sed -e 's/\[.*]//g' -e 's/ [^: ]*$/ /' -e 's/[^: ]* //g' -e 's/ /\n/' file.txt
(This assumes that your sed recognizes \n in the replacement string as a literal newline. There are simple workarounds available if it doesn't, but let's not go there if it's not necessary.)
In brief, we first replace any text between square brackets. (This needs to be improved if your input could contain multiple sequences of square brackets on a line with normal text between them. Your example only shows nested square brackets, but my approach is probably too simple for either case.) Then, we remove any words which don't contain a colon, with a special provision for the last word on the line, and some subsequent cleanup. Finally, we replace any remaining spaces with newlines, and (implicitly) print whatever is left. (This still ends up printing one newline too many, but that is easy to fix up later.)
Alternatively, we could use sed to remove any bracketed expressions, then use grep on the remaining tokens.
sed -e :a -e 's/\[[^][]*\]//' -e ta file.txt |
grep -ow '[^[:space:]]*:[^[:space:]]*'
The :a creates a label a and ta says to jump back to that label and try again if the regex matched. This one also demonstrates how to handle nested and repeated brackets. (I suppose it could be refactored into the previous attempt, so we could avoid the pipe to grep. But outlining different solution models is also useful here, I suppose.)
If you wanted to ensure that there is at least one non-colon character adjacent to the colon, you could do something like
... file.txt |
grep -owE '[^:[:space:]]+:[^[:space:]]*|[^[:space:]]*:[^: [:space:]]+'
where the -E option selects a slightly more modern regex dialect which allows us to use | between alternatives and + for one or more repetitions. (Basic grep in 1969 did not have these features at all; much later, the POSIX standard grafted them on with a slightly wacky syntax which requires you to backslash them to remove the literal meaning and select the metacharacter behavior... but let's not go there.)
Notice also how [^:[:space:]] matches a single character which is not a colon or a whitespace character, where [:space:] is the (slightly arcane) special POSIX named character class which matches any whitespace character (regular space, horizontal tab, vertical tab, possibly Unicode whitespace characters, depending on locale).
Awk easily lets you iterate over the tokens on a line. The requirement to ignore matches within square brackets complicates matters somewhat; you could keep a separate variable to keep track of whether you are inside brackets or not.
awk '{ for(i=1; i<=NF; ++i) {
if($i ~ /\]/) { brackets=0; next }
if($i ~ /\[/) brackets=1;
if(brackets) next;
if($i ~ /:/) print $i }' file.txt
This again hard-codes some perhaps incorrect assumptions about how the brackets can be placed. It will behave unexpectedly if a single token contains a closing square bracket followed by an opening one, and has an oversimplified treatment of nested brackets (the first closing bracket after a series of opening brackets will effectively assume we are no longer inside brackets).
A combined solution using sed and awk:
sed 's/ /\n/g' test.txt | gawk 'i==0 && $0~/:$/{ print $0 }/\[/{ i++} /\]/ {i--}'
sed will change all spaces to a newline
awk (or gawk) will output all lines matching $0~/:$/, as long as i equals zero
The last part of the awk stuff keeps a count of the opening and closing brackets.
Another solution using sed and grep:
sed -r -e 's/\[.*\]+//g' -e 's/ /\n/g' test.txt | grep ':$'
's/\[.*\]+//g' will filter the stuff between brackets
's/ /\n/g' will replace a space with a newline
grep will only find lines ending with :
A third on using only awk:
gawk '{ for (t=1;t<=NF;t++){
if(i==0 && $t~/:$/) print $t;
i=i+gsub(/\[/,"",$t)-gsub(/\]/,"",$t) }}' test.txt
gsub returns the number of replacements.
The variable i is used to count the level of brackets. On every [ it is incremented by 1, and on every ] it is decremented by one. This is done because gsub(/\[/,"",$t) returns the number of replaced characters. When having a token like [[][ the count is increased by (3-1=) 2. When a token has brackets AND a semicolon my code will fail, because the token will match, if it ends with a :, before the count of the brackets.

Getting only grep exact matches

I am trying to grep a file for the exact occurrence of a match, but I get also longer spurious matches:
grep CAT1717O99 myfile.txt -F -w
Output:
CAT1717O99
CAT1717O99.5
I would like to output only the first exactly matching line. Is there any way to get rid of the second line?
Thanks in advance.
Arturo
This is the file 'myfile.txt':
CAT1717O99
CAT1717O99.5
This will do the work for you.
grep -Fx "CAT1717O99" textfile
-F means Fixed
-x mean exact
Use the power of Perl-compatible regular expression (PCRE) and search the matches to the given pattern:
grep -Po "\bCAT1717O99(\s|$)" myfile.txt
(\s|$) - alternative group, ensures matching substring CAT1717O99 if it's followed by whitespace or placed at the end of the line
-P option, allows regular expressions
-o option, prints only matched parts of matching lines
You'll need explicitly request spaces in order to ignore special chars.
grep -E '(^| )CAT1717O99( |$)' myFile.txt
from grep manual :
-w, --word-regexp
Select only those lines containing matches that form whole words. The test is that the matching substring must either be at the beginning of the line, or preceded by a non-word constituent character. Similarly, it must be either at the end of the line or followed by a non-word constituent character. Word-constituent characters are letters, digits, and the underscore.

Double \\ in regular expression iOS

Does anyone understand what this (([A-Za-z\\s])+)\\? means?
I wonder why it should be "\\s" and "\\" ?
If I entered "\s", Xcode just doesn't understand and if I entered "\?", it just doesn't match the "?".
I have googled a lot, but I did not find a solution. Anyone knows?
The actual regex is (([A-Za-z\s])+)\?. This matches one or more letters and whitespace characters followed by an question mark. The \ has two different meanings here. In the first instance \s has a fixed meaning and stands for any white space characters. In the second instance the \? means the literal question mark character. The escaping is necessary as the question mark means one or none of the previous otherwise.
You can't type your regex like this in a string literal in C code though. C also does some escaping using the backslash character. For example "\n" is translated to a string containing only a newline character. There are some other escape sequences with special meanings. If the character after the backslash doesn't have a special meaning the backslash is just removed. That means if you want to have a single backspace in your string you have to write two.
So if you wrote your regex string as you wanted you'd get different results as it would be interpreted as (([A-Za-zs])+)? which has a completely different meaning. So when you write a regex in an ObjC (or any other C-based language) string literal you must double all backslash characters.
not sure about ios but same thing happens in java. \ is escape character for java,and c also so when you type \s java reads \ as an escape character.
think of it as if you want to print a \ what will you have to do.
you will have to type \\. now first \ will work as escape character for java and second one will be printed.
I think it should be the same concept for ios too.
so if you want \s you type \s, if you want \ you type \\.
The \s metacharacter is used to find a whitespace character.
Refer this!

How can I enter quotes or apostrophes in neo4j

Trying to enter the following text fails:
MERGE (people:People {Person:'Abe N. O'Sullivan'})
Replacing the apostrophe with a ’ works, but I wonder if there is a more ellegant solution.
Use double quotes, and it will work fine:
MERGE (people:People {Person:"Abe N. O'Sullivan"})
Note if this were the name of a property, you can use backticks to escape the name of a property that has spaces or special characters in it. For text literals, you can surround them with either single or double quotes. If you want to put a quote inside of a text literal quote, you either need to use the other kind of quote to surround the string, or you need to escape it with backslash, I believe.

why to use singlequotes and \ in the patterens in grep command?

In some book I have seen a grep command example as
$grep '^no(fork\|group)' /etc/group
I need explanation for "why to use single quotes for the patteren and \ before the characters ( | )".
The advantage of using single quotes with grep, is that you do not need to escape double quotes when you need to grep for them. For example, if you wanted to search for "findthis" (including searching for the quotes) with grep, using single quotes, it would look like this:
grep '"findthis"' yourfile.txt
If you were using double quotes you would need to escape the quotes with a \, so it would look like this:
grep "\"findthis\"" yourfile.txt
The reason a backslash is needed to search for certain characters is that grep assumes that those characters have special meanings. For example grep uses " to find out the beginning and end of what you are searching for (among other things). But that means that you cannot ever search for " unless there is some way around this. The solution is to place a \ before the " like so: \". If you do that, then grep knows that you actually want to search for " rather than end the string.
quoting arguments for a command is always recommended. single quote won't expand variable. in your example, it makes no different to use single/double quotes.
take an example:
kent$ cat f
foo
bar
ooo
without quote:
kent$ grep foo|bar f
zsh: correct 'bar' to 'bzr' [nyae]? n
zsh: command not found: bar
you see, my zsh thought you want to pipe output to a command "bar"
now why escape |:
Assume your grep is not an alias. grep use BRE by default, in BRE you need to escape some char to give them special meaning, | is one of them.
You can however let grep work in ERE or PCRE mode, with -E, -P option. then you don't need escape those char any longer:
kent$ grep -E 'foo|bar' f
foo
bar
in ERE or PCRE, you escape some char, to take the special meaning away.

Resources