Por que o grep ignora o '.' inicial?

Você usou grep -E, exigindo Expressões Regulares Estendidas (EREs). Dot sempre deve ser escapado como literal. O ponto de interrogação é um operador válido para EREs, portanto, para corresponder como literal, ele também deve ter escape:

echo 'href="./download/file.php?id=86753"' |
    grep -Eo '\./download/file.php\?id=[0-9]+'

Você perguntou,

Por que o grep ignora o '.' inicial?

Parece que o problema é a falha em reconhecer o líder. (ponto) na string.

Seu padrão corresponde e requer um ponto literal (é isso que \.significa). No entanto, a string que você descreveu na sua pergunta não aparece na página da web que você está tentando pesquisar. grepnão ignora isso; isso exige. Olhar:

xmlstarlet format --html BDegguyM 2>/dev/null |
    xmlstarlet select -T -t -v '//a[@class="postlink"]/@href' -n

  https://forums.raspberrypi.com/download/file.php?id=86753
  https://web.archive.org/web/20190824162104/https://www.raspberrypi.org/forums/download/file.php?id=62517&sid=907ab04af81e19ad758c5bcf8ebdca32

Presumo que você queira o primeiro deles, então vamos extrair esse:

xmlstarlet format --html BDegguyM 2>/dev/null |
    xmlstarlet select -T -t -v '//dl[@class="file"]//a[@class="postlink"]/@href' -n

  https://forums.raspberrypi.com/download/file.php?id=86753

Se você quiser apenas a parte começando, /downloadvocê pode retirá-la facilmente

xmlstarlet format --html BDegguyM 2>/dev/null |
    xmlstarlet select -T -t -v '//dl[@class="file"]//a[@class="postlink"]/@href' -n |
    sed -E 's!^https?://[^/]+!!'

  /download/file.php?id=86753

Se você realmente deseja usar grepa ferramenta certa para o trabalho, isso retornará o mesmo resultado:

grep -Po 'https?://[^/]+\K/download/file.php\?id=\d+' BDegguyM

  /download/file.php?id=86753

A resposta à pergunta na sua linha de assunto:

Por que o grep ignora o '.' inicial?

é simplesmente - isso não acontece.

Usando as duas linhas de entrada de amostra que você forneceu juntas em um arquivo:

$ cat dlfile.html
href="./download/file.php?id=86753"
href="https://web.archive.org/web/20190824162104/https://www.somewhere.com/forums/download/file.php?id=62517&sid=907ab04af81e19ad758c5bcf8ebdca32"

e apenas removendo as barras invertidas indesejáveis ​​(provavelmente inofensivas, mas definitivamente dependendo do comportamento indefinido por POSIX) antes do /s e executando os 2 grepcomandos em sua pergunta:

$ grep -Eo '\./download/file\.php\?id=[0-9]+' dlfile.html
./download/file.php?id=86753

$ grep -Eo '/download/file\.php\?id=[0-9]+' dlfile.html
/download/file.php?id=86753
/download/file.php?id=62517

O primeiro grep, que inclui um início ., corresponde apenas à string da entrada que tem um início, .enquanto o segundo grep, que não inclui um início ., sem surpresa corresponde a 2 strings da entrada que não começam com um ..

Em relação ao seu comentário sobre o primeiro grepacima:

Mas isso não encontra nada no arquivo html.

qualquer então:

1. O comando grep na sua pergunta não é o mesmo que você está usando ou
2. O arquivo HTML real não contém as strings que você forneceu para usarmos como amostra de entrada

portanto, não há realmente nada que possamos fazer para ajudá-lo a depurar um comando que você está usando para analisar alguma entrada quando não sabemos a aparência do seu comando ou não sabemos como é a sua entrada.

Houve muitos comentários aqui. Alguns deles levantaram preocupações e questões válidas. Acredito que finalmente resolvi o problema e estou postando isso aqui em um esforço para encerrar.

Como você deve ter percebido, eu estava "raspando" uma URL em busca de uma string contendo um item de informação que eu precisava. Desenvolvi um script para "automatizar" essa tarefa, talvez há 2 anos, e funcionou perfeitamente. O script faz duas coisas principais:

1. curle grepa página da web
2. tomar outras medidas com base no grepresultado

"Algo mudou" há alguns dias. Meu script "confiável" começou a gerar um erro durante cada execução; a indicação de erro sugeria que grepnão estava conseguindo encontrar a string. O que grepeu estava usando:

curl blah-blah | grep -o '\.\/download\/file\.php?id.[0-9]*'

Até agora, ainda não sei tudo o que mudou. Acredito que uma das mudanças é que o site foi terceirizado para uma empresa chamada “CloudFlare”; outra parece ser que eles não lidam mais com curldownloads da mesma forma que lidam com downloads de um navegador. Mudanças adicionais parecem estar ocorrendo.

A confusão refletida na minha pergunta se deve em parte a essas alterações no site, mas se deve principalmente a mim . Eu deveria ter sido paciente e investigado o erro mais detalhadamente antes de postar uma pergunta. Minhas desculpas a todos os envolvidos.

Uma coisa que afirmo ter aprendido com essa experiência: grepnão é a ferramenta correta para analisar HTML . Tenho duas referências para compartilhar:

1. Este tópico polêmico do SO está usando regexes para analisar HTML

2. Esta postagem informativa de Hiks Gerganov intitulada "Análise de HTML para extrair texto entre tags HTML no Shell".

Funciona bem aqui se eu mudar \/para plain /:

#!/usr/bin/sh

printf 'href="%s"\n' \
       './download/file.php?id=86753' \
       'elsewhere/download/file.php?id=86753' |
    grep -oE '\./download/file\.php\?id=[0-9]+'

Saída:

./download/file.php?id=86753

Você também pode considerar adicionar \Bno início e \bno final para melhor rejeição de quase-acidentes indesejados.