I have a list of number in a file with format: {integer}\n . So a possible list is:
3
12
53
23
18
32
1
4
i want to use grep to get the count of a specific number, but grep -c "1" file results 3 because it takes into account except the 1, the 12, 18 also. How can i correct this?
Although all the answers until now are logical, and i thought of them and tested before, actually nothing works:
username#domain2:~/code/***/project/random/r2$ cat out.txt
2
16
11
1
13
2
1
16
16
9
username#domain2:~/code/***/project/random/r2$ grep -Pc "^1$" out.txt
0
username#domain2:~/code/***/project/random/r2$ grep -Pc ^1$ out.txt
0
username#domain2:~/code/***/project/random/r2$ grep -c ^1$ out.txt
0
username#domain2:~/code/***/project/random/r2$ grep -c "^1$" out.txt
0
username#domain2:~/code/***/project/random/r2$ grep -xc "^1$" out.txt
0
username#domain2:~/code/***/project/random/r2$ grep -xc "1" out.txt
0
Use the -x flag:
grep -xc 1 file
This is what it means:
-x, --line-regexp
Select only those matches that exactly match the whole line.
There a some other ways you can do this besides grep
$ cat file
3 1 2 100
12 x x x
53
23
18
32
1
4
$ awk '{for(i=1;i<=NF;i++) if ($i=="1") c++}END{print c}' file
2
$ ruby -0777 -ne 'puts $_.scan(/\b1\b/).size' file
2
$ grep -o '\b1\b' file | wc -l
2
$ tr " " "\n" < file | grep -c "\b1\b"
2
Use this regex...
\D1\D
...or ^1$ with multiline mode on.
Tested with RegExr and they both work.
Use e.g. ^123$ to match "Beginning of line, 123, End of line"
grep -wc '23' filename.txt
It will count the number of exact matches of digit 23.
Related
I saw this question: count (non-blank) lines-of-code in bash
I understand this pattern is correct.
grep -vc ^$ filename
Why this pattern returns same result?
grep -c '[^ ]' filename
What is trick in '[^ ]'?
$ printf 'foo 123\n \nxyz\n\t\n' > ip.txt
$ cat -T ip.txt
foo 123
xyz
^I
$ grep -vc '^$' ip.txt
4
$ grep -c '[^ ]' ip.txt
3
$ grep -c '[^[:blank:]]' ip.txt
2
grep -c '[^ ]' counts any line that has a non-space character. For example, foo 123 will be counted since alphabets are not space characters. So, which one to use depends on whether a line containing only space characters should be counted or not.
I'm using Docker client Version: 18.09.2.
When I run start a container interactively and run a date command, then pipe its output to hexdump for inspection, I'm seeing a trailing \n as expected:
$ docker run --rm -i -t alpine
/ # date | hexdump -c
0000000 T h u M a r 7 0 0 : 1 5
0000010 : 0 6 U T C 2 0 1 9 \n
000001d
However, when I pass the date command as an entrypoint directly and run the container, I get a \r \n every time there's a new line in the output.
$ docker run --rm -i -t --entrypoint=date alpine | hexdump -c
0000000 T h u M a r 7 0 0 : 1 6
0000010 : 1 9 U T C 2 0 1 9 \r \n
000001e
This is weird.
It totally doesn't happen when I omit -t (not allocating any TTY):
docker run --rm -i --entrypoint=date alpine | hexdump -c
0000000 T h u M a r 7 0 0 : 1 7
0000010 : 3 0 U T C 2 0 1 9 \n
000001d
What's happening here?
This sounds dangerous, as I use docker run command in my scripts, and if I forget to omit -t from my scripts, the output I'll collect from docker run command will have invisible/non-printible \r characters which can cause all sorts of issues.
tldr; This is a tty default behaviour and unrelated to docker. Per the ticket filed on github about your exact issue.
Quoting the relevant comments in that ticket:
Looks like this is indeed TTY by default translates newlines to CRLF
$ docker run -t --rm debian sh -c "echo -n '\n'" | od -c
0000000 \r \n
0000002
disabling "translate newline to carriage return-newline" with stty -onlcr correctly gives;
$ docker run -t --rm debian sh -c "stty -onlcr && echo -n '\n'" | od -c
0000000 \n
0000001
Default TTY options seem to be set by the kernel ... On my linux host it contains:
/*
* Defaults on "first" open.
*/
#define TTYDEF_IFLAG (BRKINT | ISTRIP | ICRNL | IMAXBEL | IXON | IXANY)
#define TTYDEF_OFLAG (OPOST | ONLCR | XTABS)
#define TTYDEF_LFLAG (ECHO | ICANON | ISIG | IEXTEN | ECHOE|ECHOKE|ECHOCTL)
#define TTYDEF_CFLAG (CREAD | CS7 | PARENB | HUPCL)
#define TTYDEF_SPEED (B9600)
ONLCR is indeed there.
When we go looking at the ONLCR flag documentation, we can see that:
[-]onlcr: translate newline to carriage return-newline
To again quote the github ticket:
Moral of the story, don't use -t unless you want a TTY.
TTY line endings are CRLF, this is not Docker's doing.
Why does grep -v POLYGON remove many more lines than those matching grep POLYGON?
$ cat BOUNDARIES3D_LV03.nt | grep -v POLYGON | wc
249 782 137001
$ cat BOUNDARIES3D_LV03.nt | grep POLYGON | wc
2441 2753697 51833677
$ cat BOUNDARIES3D_LV03.nt | wc
73078 2975809 91746795
Is this a bug in grep (using: grep (GNU grep) 2.23) or am I misunderstanding something?
Update
It seems that grep aborts at the first matching line containing an invalid character.
The problem was that grep aborts at the first line containing a byte sequence that doesn't evaluate to a character in the current encoding. The following resolved the issue for me:
export LC_ALL="en_US.UTF-8"
There are file a and b, and want to find common lines and diff lines.
➜ ~ cat a <(echo) b
1
2
3
4
5
1
2
a
4
5
#find common lines
➜ ~ grep -F -f a b
1
2
4
5
#find b-a
➜ ~ grep -F -v -f a b
a
everything is ok, but when have empty line in one file, the grep can't work, see below
# add an empty line in file a
➜ ~ cat a
1
2
3
4
5
# content a is not common
➜ ~ grep -F -f a b
1
2
a
4
5
# b-a is nothing
➜ ~ grep -F -v -f a b
why is so, why once have empty line, grep can't work correctly?
in addition, use grep to find common elements have another problem, e.g.
➜ ~ cat a <(echo) b
1
2
3
4
5
6
1
2
a
4
5
6_id
➜ ~ grep -F -f a b
1
2
4
5
6_id
Can you use comm and diff instead of grep?
to find common lines use:
comm -12 a b
to find diff line:
diff a b
I have a grep command that gives the following string:
20121121001100 18 0 16 2 18
but I would like to modify this string to get
20121121 001 18 0 16 2 18
the above value are being extracted by the following:
for i in `ls -1 file.txt | sort`; do echo $i`
grep datetime $i | wc -l ``
grep abc $i | wc -l ``
grep def $i | wc -l ``
grep ghi $i | wc -l ``
grep jkl $i | wc -l ` ; done | cut -c9-500
cut -c9-500 is used because the original string is in the form of
datetime20121121001100 18 0 16 2 18
and cut -c9-500 returns
20121121001100 18 0 16 2 18
Can someone please help me to get
20121121 001 18 0 16 2 18
(ie remove the last 3 digits from the date part)
Most of what you want/do can be accomplished with awk. But for the minimum you want:
for i in `ls -1 file.txt | sort`; do echo $i`
grep datetime $i | wc -l ``
grep abc $i | wc -l ``
grep def $i | wc -l ``
grep ghi $i | wc -l ``
grep jkl $i | wc -l ` ; done | cut -c9-500 | awk '{print substr($0,1,11) substr($0,15) }'
awk is very capable at text processing.
Edit: I'm not sure of what are you doing, but, basicly this does (almost) the same:
awk 'FILENAME != oldfilename {oldfilename = FILENAME; dt = 0 ; a = 0; d = 0; g = 0; j = 0}
/datetime/ {dt++}
/abc/ {a++}
/def/ {d++}
/ghi/ {g++}
/j/ {j++}
END {print FILENAME, dt, a, d, g, j}' *
And it's faster, fewer processes, etc... Basically awk process the file, counts the occurences of the specified strings, and when it finishes the file (after the last line) prints the report.
Changed specs:
for i in `ls -1 file.txt | sort`; do echo $i`
grep datetime $i | wc -l ``
grep abc $i | wc -l ``
grep def $i | wc -l ``
grep ghi $i | wc -l ``
grep jkl $i | wc -l ` ; done | cut -c9-500 | awk '{print substr($0,1,8) " " substr($0,9,4) substr($0,15) }'
Pipe to sed:
echo "20121121001100 18 0 16 2 18" | sed -r 's/^([0-9]+)[0-9][0-9][0-9] (.*)$/\1 \2/'
gives
20121121001 18 0 16 2 18