Как подсчитать новые строки с помощью Grep в убунту

Question

(одна Конечная нота, в начале вопрос: я решил это, прежде чем спрашивать, прокрутите до конца)

Я нахожусь в процессе попытки разобрать большой файл, и до того, как я вношу изменения, я подумал, что буду запускать некоторые «простые» тесты, чтобы подтвердить, что получаю желаемый результат, но я не понимаю.

здесь происходит захват формата файла:

00000030 32 2e 31 2e 30 65 2c 0d 0a 43 4c 49 45 4e 54 5f |2.1.0e,..CLIENT_| 
00000040 44 45 4d 4f 2c 31 2c 31 2c 22 4c 4b 44 55 41 32 |DEMO,1,1,"LKDUA2| 

То, что я хочу сделать, это преобразовать все переводы строк \x0d\x0a или \r\n в чем-то еще я использовал \x09 или \t для этой цели, так что я мог повторно проанализировать его и преобразовать только некоторые из них в новые строки.

Я понимаю, что есть, вероятно, лучшие способы сделать это, но я пытался работать с тем, что я уже (думал я) знал.

первый я провел несколько испытаний:

tr -s '\r\n' '\t' <orig> o.rnt 
tr -s '\n' '\t' <orig> o.nt 
tr -s '\r' '\t' <orig> o.rt 

и размеры файлов:

$ ls -l o* 
-rw-r----- 1 madivad madivad 620519 Oct 30 09:41 orig 
-rw-rw-r-- 1 madivad madivad 620519 Oct 30 09:26 o.nt 
-rw-rw-r-- 1 madivad madivad 620519 Oct 30 09:26 o.rt 
-rw-rw-r-- 1 madivad madivad 615271 Oct 30 09:40 o.rnt 

Эти результаты, как и ожидалось. разница составляет 5248, что является числом новых строк. Все идет нормально.

, что случилось с дополнительной вкладки

я добавил еще один тест и вещи не были, как и ожидалось:

tr -s '\r\n' '\t\t' <orig> o.rntt 

-rw-rw-r-- 1 madivad madivad 615271 Oct 30 09:40 o.rntt 

Я ожидал 620519, но шестнадцатеричного подтверждает только 1x \t был добавлен назад

00000030 32 2e 31 2e 30 65 2c 09 43 4c 49 45 4e 54 5f 44 |2.1.0e,.CLIENT_D| 

(примечание: этот вопрос (Q1) является более случайным вопросом, я обнаружил это только при подтверждении всего, чтобы задать этот вопрос, мои РЕАЛЬНЫЕ вопросы являются bel вл)

Как правильно проверить или сосчитайте новой строки '

В управлении моих тестов, я хотел бы рассчитывать вхождения newline-х, и я подтвердил это несколькими способами, в результате чего в правильном 5248 ... для НЕКОТОРЫХ результатов. Кажется, что \n не разобрался правильно.

$ grep -c^orig 
5248 
$ grep -c -P '\r' orig 
5248 
$ grep -c -P '\r' o.rt 
5248 
$ grep -c -P '\x0d' o.rt 
5248 
$ grep -c -P '\t' o.rnt 
1 
$ grep -c -P '\n' orig 
0 
$ grep -c -P '\x0a' orig 
0 
$ grep -c -P '\r\n' orig 
0 

Подтверждение преобразования и тестирования

$ hexdump -C -s 48 -n 32 orig 
00000030 32 2e 31 2e 30 65 2c 0d 0a 43 4c 49 45 4e 54 5f |2.1.0e,..CLIENT_| 

$ hexdump -C -s 48 -n 32 o.rt 
00000030 32 2e 31 2e 30 65 2c 09 0a 43 4c 49 45 4e 54 5f |2.1.0e,..CLIENT_| 

$ hexdump -C -s 48 -n 32 o.nt 
00000030 32 2e 31 2e 30 65 2c 0d 09 43 4c 49 45 4e 54 5f |2.1.0e,..CLIENT_| 

$ hexdump -C -s 48 -n 32 o.rnt 
00000030 32 2e 31 2e 30 65 2c 09 43 4c 49 45 4e 54 5f 44 |2.1.0e,.CLIENT_D| 

В случае выходных файлов, tr '\r\n' '\t' <orig> o.rnt, кажется, сделать работу правильно, но мой grep для тестирования является неправильным:

$ hexdump -C -n 600 o.rnt | grep -P ' 09 ' 
00000030 32 2e 31 2e 30 65 2c 09 43 4c 49 45 4e 54 5f 44 |2.1.0e,.CLIENT_D| 
00000110 2c 22 22 2c 31 2c 2c 09 43 4c 49 45 4e 54 5f 41 |,"",1,,.CLIENT_A| 
000001a0 22 22 2c 30 2c 22 22 2c 09 43 4c 49 45 4e 54 5f |"",0,"",.CLIENT_| 
00000200 73 65 2c 46 61 6c 73 65 2c 30 2c 09 43 4c 49 45 |se,False,0,.CLIE| 
00000230 31 2c 09 43 4c 49 45 4e 54 5f 43 4e 53 4e 54 2c |1,.CLIENT_CNSNT,| 

$ grep -c -P '\t' o.rnt 
1 

и где я использовал: tr -s '\n' '\t' <orig> o.nt он также оказался для работы, опять мой тест неправильный:

$ hexdump -C -n 600 o.nt | grep -P ' 09 ' 
00000030 32 2e 31 2e 30 65 2c 0d 09 43 4c 49 45 4e 54 5f |2.1.0e,..CLIENT_| 
00000110 30 2c 22 22 2c 31 2c 2c 0d 09 43 4c 49 45 4e 54 |0,"",1,,..CLIENT| 
000001a0 22 2c 22 22 2c 30 2c 22 22 2c 0d 09 43 4c 49 45 |","",0,"",..CLIE| 
00000200 46 61 6c 73 65 2c 46 61 6c 73 65 2c 30 2c 0d 09 |False,False,0,..| 
00000230 2c 31 32 30 31 2c 0d 09 43 4c 49 45 4e 54 5f 43 |,1201,..CLIENT_C| 

$ grep -c -P '\t' o.nt 
1 

Благодаря

Я не хочу, чтобы двигаться вперед, пока я не понимаю, куда я иду неправильно, так что я не еще больше усугубит проблему :)

Я работал это из

Как уже говорилось выше, я на самом деле работал его, но теперь можно спросить:

1. есть ли лучший способ?

Это тест, который я придумал, я был бы рад за любые усовершенствования:

$ grep -o -P '\t' o.nt | wc -l 
5249 

Ах да, и есть одна дополнительная \t, потому что есть на самом деле одна дополнительная вкладка в файле (длинная история)

Оглядываясь на него в ретроспективе, как бы считать его, используя hexdump, помня о пересечениях линий? т.е. считать или дисплей 0D 0A

Answer 1

При этом мой заключительный тест, я, наконец, IT

я все готово, чтобы разместить этот вопрос, и как это случилось со мной много раз в прошлом, задавая stackexchange вопрос имеет привел к тому, что я изучил ответ, прежде чем опубликовать его.

Я занимаюсь этим уже более часа, но вижу ошибку моих путей. Я до сих пор отправляю это, потому что он взял меня все это время, чтобы узнать, и, возможно, это могло бы предотвратить, что для других:/

Я забыл, что grep -c подсчитает число строк и удаление newline характера, я буду только имеют одну строку в файле :(

Я придумал этот тест:.

$ grep -o -P '\t' o.nt | wc -l 
5249