Por que a classe de caractere de dígito de expressão regular inclui o caractere CR se o último dígito estiver no final da linha?

0

Eu queria extrair o tamanho do Content-Length de um URL e gerar o URL + $ size na mesma linha.

Os dados com os quais trabalhei:

> curl -I -s http://yahoo.com
HTTP/1.1 301 Redirect
Date: Thu, 10 Mar 2016 13:58:34 GMT
Via: https/1.1 ir18.fp.bf1.yahoo.com (ApacheTrafficServer)
Server: ATS
Location: https://www.yahoo.com/
Content-Type: text/html
Content-Language: en
Cache-Control: no-store, no-cache
Connection: keep-alive
Y-Trace: BAEAQAAAAADEVnKTAIhTVAAAAAAAAAAA52rmwEDlxSwAAAAAAAAAAAAFLbI13bX.AAUtsjXdvxvBYm3xAAAAAA--
Content-Length: 304

Aqui está um exemplo simplificado. Eu extraí o conteúdo de comprimento e apenas cortar o campo que eu preciso. Em vez do URL, apenas ecoo um "a":

> size=$(curl -I -s http://yahoo.com | grep "Content-Length:" | cut -f2 -d" "); echo $size"a"
> a04

O "a" sobrescreve o primeiro dígito.

Acontece que a linha de cabeçalho Content-Length é fechada com um caractere 0D e, junto com os números, vem esse retorno de carro. Eu pensei que cut não é inteligente o suficiente para deixar o 0D desligado, mas simplesmente mudando a extração para alguma ferramenta regexp se comporta da mesma forma:

> size=$(curl -I -s http://yahoo.com | grep "Content-Length:" | sed 's/Content-Length: \([[:digit:]]*\)//'); echo $size"a"
> a04

O que significa que a classe de caractere [[: digit:]] também incluiu o caractere 0D. Tentei marcar explicitamente o final da string e funcionou:

> size=$(curl -I -s http://yahoo.com | grep "Content-Length:" | sed 's/Content-Length: \([[:digit:]]*\).*//'); echo $size"a"
> 304a

TL; DR: por que a classe de caracteres regexp incluiu o caractere 0D?

    
por karatedog 10.03.2016 / 15:46

1 resposta

1

Não aconteceu.

strintg:     Content-Length: 304
strintg:     Content-Length: 304%pre%d
matched:     Content-Length: 304
replaced by:                 304
result:                      304%pre%d
d matched: Content-Length: 304 replaced by: 304 result: 304%pre%d

Não foi correspondido e, portanto, não foi removido. Apenas ficou lá.

    
por 10.03.2016 / 15:56