Como tratar os finais de linha CRLF no grep?

Question

Suponha que eu tenha uma entrada de texto arbitrária que contenha terminações de linha CRLF:

$ curl -sI http://unix.stackexchange.com | head -4
HTTP/1.1 200 OK
Cache-Control: public, max-age=60
Content-Length: 80551
Content-Type: text/html; charset=utf-8

$ curl -sI http://unix.stackexchange.com | head -4 | hexdump -C
00000000  48 54 54 50 2f 31 2e 31  20 32 30 30 20 4f 4b 0d  |HTTP/1.1 200 OK.|
00000010  0a 43 61 63 68 65 2d 43  6f 6e 74 72 6f 6c 3a 20  |.Cache-Control: |
00000020  70 75 62 6c 69 63 2c 20  6d 61 78 2d 61 67 65 3d  |public, max-age=|
00000030  36 30 0d 0a 43 6f 6e 74  65 6e 74 2d 4c 65 6e 67  |60..Content-Leng|
00000040  74 68 3a 20 38 30 39 30  32 0d 0a 43 6f 6e 74 65  |th: 80902..Conte|
00000050  6e 74 2d 54 79 70 65 3a  20 74 65 78 74 2f 68 74  |nt-Type: text/ht|
00000060  6d 6c 3b 20 63 68 61 72  73 65 74 3d 75 74 66 2d  |ml; charset=utf-|
00000070  38 0d 0a                                          |8..|
00000073

O GNU grep 2.26 não lida muito bem com essa entrada em relação a terminações de linha:

$ curl -sI http://unix.stackexchange.com | head -4 | grep '200 OK$'
$ curl -sI http://unix.stackexchange.com | head -4 | grep '200 OK.$'
HTTP/1.1 200 OK

Isso é um pouco chato. Naturalmente, posso resolver isso incluindo dos2unix no pipeline:

$ curl -sI http://unix.stackexchange.com | head -4 | dos2unix | grep '200 OK$'
HTTP/1.1 200 OK

mas isso parece um pouco bloqueado (e não muito portátil).

O mais estranho em geral é que a página grep(2) man afirma que a ferramenta irá remover quaisquer CRs na entrada, a menos que a entrada tenha sido detectada como binária:

-U, --binary
       Treat the file(s) as binary.  By default, under MS-DOS and MS-Windows,
       grep guesses whether a file is text or binary  as  described  for  the
       --binary-files  option.   If  grep decides the file is a text file, it
       strips the CR characters from the  original  file  contents  (to  make
       regular  expressions  with  ^  and  $  work correctly).  Specifying -U
       overrules this guesswork, causing all files to be read and  passed  to
       the matching mechanism verbatim; if the file is a text file with CR/LF
       pairs  at  the  end  of  each  line,  this  will  cause  some  regular
       expressions  to  fail.   This  option has no effect on platforms other
       than MS-DOS and MS-Windows.

EDITAR: Conforme mencionado na manpage, esse comportamento é específico para MS-DOS e MS-Windows.

É possível fazer grep manipular transparentemente os terminais de linha CRLF (e CR) sem pré-processar a entrada? Se não, isso é algo que deve ser consertado, ou existe uma justificativa bem fundamentada?

    

Answer 1

com base nesta página. tente estas soluções

link

curl -sI http://unix.stackexchange.com | head -4  | grep "200 OK$(printf '\r')" 

grep -IUlr $'\r'