Em sistemas GNU/Linux, especialmente em contextos embarcados como o Raspberry Pi, BeagleBone, ou outros SBCs (Single Board Computers), o comportamento de comandos e scripts pode variar drasticamente dependendo da configuração regional, ou localidade do sistema.

Essas configurações são controladas por variáveis de ambiente como LANG, LC_ALL, LC_COLLATE e outras, que determinam como caracteres são interpretados, ordenados, e exibidos. Tais configurações afetam desde ordenações (sort, ls) até a forma como nomes de arquivos são casados por expressões regulares ou curingas (globbing). Isso é crítico, por exemplo, ao desenvolver scripts de automação para dispositivos embarcados que manipulam arquivos, logs, sensores ou comandos baseados em localização textual.

Imagine que seu script precisa organizar arquivos por nome, processar logs em português ou lidar com valores numéricos usando , como separador decimal. Sem a localidade correta, isso pode falhar silenciosamente.

No universo dos SBCs, que são muitas vezes utilizados em dispositivos de campo e IoT, o sistema operacional pode ser simplificado e conter configurações de localidade mínimas. Nestes casos, a manipulação correta dessas variáveis se torna ainda mais crucial para garantir previsibilidade e portabilidade de comportamento, tanto no shell interativo quanto em scripts automatizados.

Nas próximas seções, exploraremos essas variáveis, como elas afetam os comandos no Bash e como manipulá-las — com atenção especial ao contexto embarcado.

Comando locale e a Visão Geral das Variáveis Regionais

Em sistemas GNU/Linux, o comando locale permite inspecionar as variáveis de ambiente relacionadas à localização. A saída desse comando mostra como o sistema interpretará aspectos culturais como idioma, ordenação de caracteres, separadores decimais, formato de data, entre outros.

Por exemplo, em uma distribuição Debian (como o Raspberry Pi OS), o comando locale pode retornar:

<code>$ locale
LANG=pt_BR.UTF-8
LANGUAGE=pt_BR:pt:en
LC_CTYPE="pt_BR.UTF-8"
LC_NUMERIC="pt_BR.UTF-8"
LC_TIME="pt_BR.UTF-8"
LC_COLLATE="pt_BR.UTF-8"
LC_MONETARY="pt_BR.UTF-8"
LC_MESSAGES="pt_BR.UTF-8"
LC_PAPER="pt_BR.UTF-8"
LC_NAME="pt_BR.UTF-8"
LC_ADDRESS="pt_BR.UTF-8"
LC_TELEPHONE="pt_BR.UTF-8"
LC_MEASUREMENT="pt_BR.UTF-8"
LC_IDENTIFICATION="pt_BR.UTF-8"
LC_ALL=

Entendendo os Valores com e sem Aspas

Alguns valores são exibidos com aspas, como LC_COLLATE="pt_BR.UTF-8", enquanto outros aparecem sem aspas, como LANG=pt_BR.UTF-8. O que isso significa?

• Os valores sem aspas indicam que a variável está explicitamente definida no ambiente.
• Os valores entre aspas são inferidos pelo utilitário locale com base nas variáveis LANG, LANGUAGE ou LC_ALL.

Esse comportamento é especialmente importante em sistemas embarcados minimalistas, nos quais pode haver apenas uma ou duas variáveis definidas no /etc/environment ou em arquivos de inicialização (/etc/profile, ~/.bashrc, etc). Scripts que dependem de ordenações específicas ou de codificações UTF-8 podem se comportar de forma errática se essas inferências não forem corretas.

Verificação com Expansão de Parâmetros

Podemos confirmar quais variáveis estão definidas usando a expansão de parâmetros do Bash:

$ echo ${LANG:-indefinida}
pt_BR.UTF-8

$ echo 
${LC_CTYPE:-indefinida}
indefinida

Isso mostra que LANG está definida diretamente, enquanto LC_CTYPE está apenas herdando seu valor indiretamente. Isso pode ser problemático se um script ou biblioteca exigir uma definição explícita de LC_*.

No caso de SBCs configurados para ambientes headless ou sem interface gráfica, é comum encontrar apenas LANG=C ou LANG=en_US.UTF-8, o que pode resultar em mensagens de erro em inglês, formatos de número com ponto ao invés de vírgula, e problemas de casamento de padrões.

Variáveis LANG, LC_ALL, LC_COLLATE e LC_CTYPE e seu Impacto em Padrões de Arquivo

No Bash, o casamento de padrões — também conhecido como globbing — permite que expressões como *.txt ou [a-z]* sejam expandidas automaticamente para os nomes de arquivos correspondentes no diretório. Porém, o comportamento dessas expressões pode variar drasticamente dependendo das variáveis de localidade configuradas no sistema.

Essas variáveis influenciam não apenas a forma como os caracteres são agrupados e ordenados, mas também como são reconhecidos acentos, maiúsculas e minúsculas, ou caracteres especiais.

As Principais Variáveis

Casos Reais em Sistemas Embarcados

Imagine um script de atualização automática rodando em um Raspberry Pi em campo, cujo objetivo é deletar arquivos antigos com nomes que começam com letra minúscula. Um comando como:

rm [a-z]*.log

Pode funcionar corretamente em um terminal, mas falhar em um script se LC_COLLATE estiver indefinida ou mal configurada. Em alguns ambientes, essa expressão incluirá também arquivos que começam com letras maiúsculas, por conta da ordenação “intercalada” do UTF-8 padrão brasileiro (aAbBcC…).

Outro exemplo: se você estiver coletando dados de sensores e salvando arquivos com nomes baseados em data (01-água.csv, 02-óleo.csv), a forma como acentos são tratados depende de LC_CTYPE. Uma falha de codificação pode impedir a abertura correta desses arquivos em um script automatizado, especialmente se a localidade estiver como C ou POSIX (ASCII puro).

Como Definir e Testar

Você pode modificar essas variáveis temporariamente na sessão atual:

LC_COLLATE=C

Ou exportá-las globalmente:

export LC_COLLATE=C

E testá-las de forma isolada para entender seus efeitos:

echo ${LC_COLLATE:-"não definida"}

Boas Práticas para SBCs

• Defina LC_ALL como C ou en_US.UTF-8 para garantir comportamento consistente.
• Use LC_COLLATE=C quando scripts dependerem de ordenações previsíveis.
• Inclua exportações explícitas nos seus scripts sh ou bash para garantir que se comportem da mesma forma em qualquer dispositivo.

A Localidade Especial C e o Controle Preciso do Comportamento do Bash

No universo das variáveis de localização, existe uma localidade especial chamada C. Diferentemente de pt_BR.UTF-8 ou en_US.UTF-8, a localidade C representa o comportamento mais básico e previsível possível, sendo praticamente universal no mundo da computação. Ela é essencial quando se busca confiabilidade em scripts shell, especialmente em sistemas embarcados com poucos recursos ou configurações regionais mínimas.

Características da Localidade C

• Usa codificação ASCII simples, de 1 byte por caractere.
• A ordenação de caracteres é feita com base direta nos valores binários (byte values).
• O agrupamento de faixas de caracteres ([a-z]) segue estritamente a sequência da tabela ASCII: A-Z (65–90) vem antes de a-z (97–122).

Essa previsibilidade é justamente o que torna LC_COLLATE=C tão poderosa: ela ignora regras culturais ou linguísticas e fornece uma base estável para o comportamento do shell.

Exemplo Prático em SBCs

Em um Raspberry Pi com sistema configurado para pt_BR.UTF-8, é comum ver listagens como:

$ ls
a.txt  A.txt  b.txt  B.txt  á.txt  é.txt

Na configuração padrão com LANG=pt_BR.UTF-8, ao executar:

$ for f in *; do echo $f; done

A saída pode parecer confusa — intercalando maiúsculas, minúsculas e acentuados — por conta do ordenamento baseado em regras linguísticas.

Ao mudar a localidade:

$ LC_COLLATE=C
$ for f in *; do echo $f; done

A ordenação se torna:

A.txt
B.txt
a.txt
b.txt
á.txt
é.txt

Essa separação limpa entre letras maiúsculas e minúsculas é extremamente útil ao criar scripts que processam arquivos em ordem, organizam logs, ou iteram sobre faixas de caracteres com for.

Comportamento com globasciiranges

O Bash possui uma opção interna chamada globasciiranges que, quando ativada, força o uso da localidade C apenas para faixas como [a-z] ou [A-Z], independentemente da localidade real do sistema.

$ shopt -u globasciiranges

Com ela desabilitada, [a-z] pode capturar tanto letras minúsculas quanto maiúsculas, conforme a regra cultural da localidade. Isso pode quebrar scripts que assumem que [a-z] só contém minúsculas. Ao configurar LC_COLLATE=C, garantimos que [a-z] funcione conforme esperado, inclusive em SBCs com localidade exótica.

Classes POSIX para Casamento de Padrões Confiáveis

Nos sistemas GNU/Linux, além do uso de faixas explícitas como [a-z] ou [A-Z], também é possível empregar classes POSIX de caracteres dentro de colchetes, o que oferece maior precisão e independência das localizações regionais. Isso é extremamente útil em sistemas embarcados, onde o suporte a codificações e regras de ordenação pode ser limitado ou inconsistente.

As classes POSIX são representadas por [:nome:], e devem ser utilizadas dentro de colchetes duplos, como [[:lower:]] ou [[:digit:]]. Diferente de faixas como [a-z], que podem se comportar de maneira diferente dependendo de LC_COLLATE, as classes POSIX sempre respeitam a definição de tipo de caractere, e não a posição em uma tabela.

Exemplos Comuns de Classes POSIX

• [[:lower:]] — todos os caracteres minúsculos (incluindo acentuados como á, ç etc).
• [[:upper:]] — todos os caracteres maiúsculos.
• [[:digit:]] — dígitos de 0 a 9.
• [[:alpha:]] — qualquer letra (maiúscula ou minúscula).
• [[:alnum:]] — letras e números.

Comparação Prática em SBCs

Suponha que você tenha os seguintes arquivos em um Raspberry Pi:

a.txt  A.txt  á.txt  b.txt  B.txt  é.txt

Se tentar listar apenas os arquivos que começam com letra maiúscula com:

ls [A-Z]*

Você pode receber resultados inesperados, dependendo de LC_COLLATE. Porém, se usar:

ls [[:upper:]]*

A listagem será precisa: apenas arquivos cujo primeiro caractere é de fato uma letra maiúscula, independentemente da localidade ou da codificação:

A.txt  B.txt

O mesmo vale para:

ls [[:lower:]]*

Retornando corretamente:

a.txt  á.txt  b.txt  é.txt

Ou seja, as classes POSIX são ideais para scripts portáteis, confiáveis e independentes de configurações regionais — exatamente o tipo de robustez que se espera em automações para sistemas embarcados, onde ambientes podem ser reconfigurados, simplificados ou até reconstruídos entre reboots.

Expansões que Não São Afetadas por LC_*: Cuidado com Intervalos {A..Z}

Embora LC_COLLATE e LC_CTYPE tenham papel fundamental no comportamento do Bash em relação a globbing (casamento de padrões como [a-z]*), elas não afetam todas as formas de expansão. Um exemplo clássico são as expansões de intervalos com chaves, como:

for f in {A..Z}; do echo "$f.txt"; done

Esse tipo de construção é gerado antes da expansão de variáveis e não passa pelas mesmas regras de collation. Ou seja, é estritamente baseado na ordem da tabela ASCII, independentemente de qualquer variável de localidade.

Exemplo Prático

Considere o seguinte diretório:

a.txt  A.txt  b.txt  B.txt  c.txt  C.txt  d.txt  D.txt  e.txt  E.txt

Se você usar uma expansão com chaves:

for f in {a..e}; do echo "$f.txt"; done

O resultado será:

a.txt
b.txt
c.txt
d.txt
e.txt

E com {A..E}:

A.txt
B.txt
C.txt
D.txt
E.txt

Agora compare com:

ls [a-e].txt

Esse comando é sensível a LC_COLLATE. Com a localidade brasileira padrão (pt_BR.UTF-8), o resultado pode incluir maiúsculas e minúsculas intercaladas, como:

a.txt  A.txt  b.txt  B.txt  c.txt  C.txt  d.txt  D.txt  e.txt

Com LC_COLLATE=C, o resultado muda para incluir apenas os que realmente começam com letras entre a e e, em ASCII puro:

a.txt  b.txt  c.txt  d.txt  e.txt

Implicações em Scripts Embarcados

É fundamental compreender que:

• Expansões com chaves ({}) são determinísticas e previsíveis.
• Casamento de padrões ([]) depende da localidade e das opções do shell.

Se você estiver escrevendo scripts para rodar em dispositivos como Raspberry Pi ou sistemas minimalistas baseados em BusyBox (muito comuns em ambientes embarcados), priorizar construções com {} pode evitar surpresas. No entanto, se a lógica depender de padrões dinâmicos com curingas, então a configuração de LC_COLLATE deve ser controlada explicitamente no início do script para garantir consistência.

Conclusão

Na maioria das vezes, a opção globasciiranges está habilitada por padrão e a localidade é definida de forma coerente. Mas, em casos onde comportamento anômalo surge — como scripts que listam arquivos de forma incorreta ou processam nomes inesperadamente —, agora você sabe exatamente onde e como atuar.

Esse conhecimento é especialmente valioso em sistemas embarcados, onde o ambiente é frequentemente construído com otimizações e simplificações que podem omitir variáveis fundamentais.

The post Como as Variáveis LANG e LC_ Influenciam o Bash: Um Guia para Sistemas Embarcados e SBCs* first appeared on MCU & FPGA.