Por que o "grep" não consegue encontrar correspondências em um script gerado pelo SQL Server, mesmo as mais triviais?

grepnão tem nenhum limite de tamanho de arquivo até onde eu saiba. É muito mais provável que seja um problema de codificação. Provavelmente há muitos pontos de código UTF-16, UTF-32 e até UTF-8 que não são codificados como 83 e cujo glifo se parece com S. O grep clássico tende a assumir a codificação ASCII.

A solução que eu usaria é identificar a codificação da seguinte forma

 file DB_Local_Backup_20250311.sql

 head -n 5 DB_Local_Backup_20250311.sql | hd -C

Onde está o encantamento atual para hexdump canônico na sua distribuição/sistema operacional?hd -c hd -C

Então você pode procurar uma sequência de bytes usando escapes hexadecimais, se necessário.

Seu arquivo é codificado em UTF-16 , little endian (LE) com uma marca de ordem de byte (BOM) e com terminações de linha Microsoft-Windows (CR, LF) em vez de terminações de linha Unix (LF). Então cada letra é escrita em um arquivo como dois bytes em vez do byte único que versões antigas do grep poderiam esperar. O arquivo, portanto, também contém uma marca de ordem de byte (BOM) nos dois primeiros bytes e um nulo antes do valor ASCII de 'S'. Qualquer um desses pode perturbar versões antigas do grep, mas acho estranho que o grep moderno tenha um problema. Eu tentaria grep --binary-files=text S filename.

Em vez de grep eu também tentaria algo como

perl -ne 'print if /S/' DB_Local_Backup_20250311.sql

ou

iconv -f UTF-16LE -t UTF-8 DB_Local_Backup_20250311.sql | grep S

PS Veja É um arquivo ANSI ou UTF8? para mais informações sobre o que a Microsoft chama enganosamente de "Unicode" e "ANSI"

PPS

$ hostnamectl | grep Oper
Operating System: Ubuntu 24.04.2 LTS
$ grep --version | head -n 1
grep (GNU grep) 3.11

$ hd -C test.sql
00000000  ff fe 55 00 53 00 45 00  20 00 5b 00 44 00 42 00  |..U.S.E. .[.D.B.|
00000010  5f 00 4e 00 61 00 6d 00  65 00 5d 00 0a 00 47 00  |_.N.a.m.e.]...G.|
00000020  4f 00 0a 00 2f 00 2a 00  2a 00 2a 00 2a 00 2a 00  |O.../.*.*.*.*.*.|
00000030  2a 00 20 00 4f 00 62 00  6a 00 65 00 63 00 74 00  |*. .O.b.j.e.c.t.|
00000040  3a 00 20 00 20 00 55 00  73 00 65 00 72 00 20 00  |:. . .U.s.e.r. .|
00000050  5b 00 44 00 42 00 5f 00  75 00 73 00 65 00 72 00  |[.D.B._.u.s.e.r.|
00000060  5d 00 20 00 20 00 20 00  20 00 53 00 63 00 72 00  |]. . . . .S.c.r.|
00000070  69 00 70 00 74 00 20 00  44 00 61 00 74 00 65 00  |i.p.t. .D.a.t.e.|
00000080  3a 00 20 00 31 00 31 00  2f 00 30 00 33 00 2f 00  |:. .1.1./.0.3./.|
00000090  32 00 30 00 32 00 35 00  20 00 31 00 31 00 3a 00  |2.0.2.5. .1.1.:.|
000000a0  33 00 32 00 3a 00 34 00  34 00 20 00 2a 00 2a 00  |3.2.:.4.4. .*.*.|
000000b0  2a 00 2a 00 2a 00 2a 00  2f 00 0a 00 43 00 52 00  |*.*.*.*./...C.R.|
000000c0  45 00 41 00 54 00 45 00  20 00 55 00 53 00 45 00  |E.A.T.E. .U.S.E.|
000000d0  52 00 20 00 5b 00 44 00  42 00 5f 00 75 00 73 00  |R. .[.D.B._.u.s.|
000000e0  65 00 72 00 5d 00 20 00  57 00 49 00 54 00 48 00  |e.r.]. .W.I.T.H.|
000000f0  4f 00 55 00 54 00 20 00  4c 00 4f 00 47 00 49 00  |O.U.T. .L.O.G.I.|
00000100  4e 00 20 00 57 00 49 00  54 00 48 00 20 00 44 00  |N. .W.I.T.H. .D.|
00000110  45 00 46 00 41 00 55 00  4c 00 54 00 5f 00 53 00  |E.F.A.U.L.T._.S.|
00000120  43 00 48 00 45 00 4d 00  41 00 3d 00 5b 00 64 00  |C.H.E.M.A.=.[.d.|
00000130  62 00 6f 00 5d 00 0a 00  47 00 4f 00 0a 00        |b.o.]...G.O...|
0000013e
$ grep S test.sql
grep: test.sql: binary file matches
$ grep --binary-file=text S test.sql
��USE [DB_Name]
/****** Object:  User [DB_user]    Script Date: 11/03/2025 11:32:44 ******/
CREATE USER [DB_user] WITHOUT LOGIN WITH DEFAULT_SCHEMA=[dbo]

Comentário do autor da pergunta :
Obviamente, a solução mais fácil é certificar-se de que o arquivo mencionado não tenha essa codificação estranha para começar. Isso pode ser resolvido salvando o script gerado pelo SQL-Server como texto ANSI, como pode ser feito a partir desta configuração:

grep é uma ferramenta tradicional que tem suas limitações. Codificações multibyte, como UTF-16 que você mencionou, são uma delas - ele não consegue lidar com elas corretamente.

Em vez de mexer manualmente nas codificações, use uma ferramenta grep mais moderna, como o ugrep .

Corresponde aos padrões Unicode por padrão e pesquisa automaticamente arquivos codificados em UTF-8, UTF-16 e UTF-32

Ele tenta detectar automaticamente o que a entrada usa. Ele funciona até mesmo com arquivos binários. Tudo o que você precisa fazer é instalá-lo ( apt install ugrepno Ubuntu) e alterar o executável no seu comando:

ug "S" DB_Local_Backup_20250311.sql