Como ignorar POSIX "aviso: substituição de comando: byte nulo ignorado na entrada"?

Isso funcionou para mim no Raspberry Pi 4 com Debian 12 Bookworm e deve ser uma solução portátil (aderindo ao POSIX).

Podemos traduzir todos os caracteres NULL com uma string vazia, excluindo efetivamente todas as suas ocorrências da string usando o trutilitário (página de manual POSIX) (sabemos que, no meu caso, há apenas uma string e um caractere NULL no final dela em ambos os casos, portanto, não removeremos vários caracteres NULL, apenas um no final da string.)

Tomemos como exemplo o primeiro arquivo mencionado (talvez seja melhor ler /proc/device-tree/modelconforme a resposta de Marcus Müller ):

rpi_model_name=$(cat /proc/device-tree/model|tr -d '\0')

ou até mesmo se livrar de cat:

rpi_model_name=$(tr -d '\0' </proc/device-tree/model)

O seguinte printfpode ser trocado por echo,.. o que deixar você confortável:

printf '%s\n' "$rpi_model_name"

deve gerar algo como:

Raspberry Pi 4 Model B Rev 1.5

Esta pode não ser a única maneira, fique à vontade para postar a sua própria ou melhorar esta resposta.

Ignorar ou excluir explicitamente um número desconhecido de zero bytes sem entender de onde eles vêm parece uma má ideia! Então, vamos ver de onde isso vem e em quais casos podemos querer removê-lo.

Em primeiro lugar, por que o erro? Uma string de shell em si é uma string terminada em zero (uma "string C" se você estiver familiarizado com essa linguagem de programação) internamente. Portanto, não pode conter o byte 0; que sempre sinaliza o fim da string. Portanto, no momento em que você tenta armazenar algo com byte zero em uma string no bash (ou qualquer outro shell POSIX), a string é "limpa" de todos os 0 bytes, caso contrário, você salvaria toda a saída nessa variável de string , mas sempre que você o ler, você obterá apenas todos os caracteres até (mas excluindo) o primeiro 0 byte. Os programadores Bash sabem que esta é uma grande fonte de bugs, então eles avisam sobre isso.

Agora, podemos remover com segurança esses bytes da entrada sem quebrá-la?

O que é isso, de acordo com a documentação do kernel :

O conteúdo de cada arquivo são os dados binários exatos da árvore de dispositivos.

E, como tal, as propriedades do tipo devicetreestring terminam em 0 byte e stringlistas propriedades do tipo são várias strings terminadas em 0 apenas concatenadas. No seu caso, o campo do modelo termina corretamente em um byte zero; isso faz parte dos dados binários exatos e, portanto, também está presente na entrada sysfs.

Como, no entanto, sabemos que será o último byte,

rpi_model_name="$(head -c -1 /proc/device-tree/base/model)"

podia funcionar. E, bônus, se isso não for realmente uma única string, mas várias strings concatenadas (você veria isso, por exemplo, nas compatibleentradas!), você ainda receberia um aviso em vez de algo quebrado sem espaços.

Claro, você pode querer lidar com isso de forma mais geral: se algo for uma lista de strings, você ainda pode querer lê-lo e usá-lo (por exemplo, para impressão) elemento a elemento ou concatenado, por exemplo, com novas linhas ou espaços.

function read_devicetree_node() {
  mapfile -d '' result < "$1"
}

## use like this

read_devicetree_node /proc/device-tree/base/model
# save the result in a variable. 
# Strange syntax, because we want to save *all* entries from `result` in `model_names`.
model_names=( ${result[@]} )
# print the first element from that `result` array we just got
printf 'First element is %s. Total elements %d.\n' "$model_names" "${#model_names[@]}"
printf 'All elements concatenated with "foobar" in between:'
printf '%sfoobar' ${model_names[@]}

function simple_devicetree_string() {
  local tmp
  mapfile -d '' tmp < $1
  printf '%s ' ${tmp[@]}
}

printf 'Let's read this simply into a line, safely: %s\n' "$(simple_devicetree_string /proc/device-tree/base/model)"

Fora isso, você não deve acessar esses caminhos /sys/firmware/devicetree/basediretamente, mas sim /proc/device-tree/base/como prefixo. É garantido que isso ainda será válido na próxima atualização do kernel, /sys/firmware/devicetree/pode ter desaparecido. ( Na verdade, esses não são arquivos armazenados em algum lugar - esta é apenas a estrutura devicetree analisada representada em sysfs. Ela é calculada pelo kernel quando você a lê, não por algum arquivo armazenado em um disco. Portanto, a existência deles é basicamente a API para o kernel aqui - e os desenvolvedores do kernel dizem "por favor acesse via /proc, a outra parte é o que usamos atualmente, mas não podemos garantir que isso não mudará. O caminho /proc, nós garantimos.")

De acordo com minha resposta para Suprimir rastreamento de execução para comando echo? , tentar

{ rpi_model_name=$(cat /proc/device-tree/model); }            2>/dev/null
{ rpi_serial_number=$(cat /proc/device-tree/serial-number); } 2>/dev/null

ou

{
  rpi_model_name=$(cat /proc/device-tree/model)
  rpi_serial_number=$(cat /proc/device-tree/serial-number)
} 2>/dev/null