C e shell no rogpOS

C e shell não competem pelo mesmo espaço no rogpOS. C sustenta o caminho interativo e de longa duração. Shell organiza tarefas curtas de inicialização, montagem e operação. A fronteira é uma escolha de segurança e manutenção.

Quando usar C

loop gráfico e entrada em tempo real;
estado persistente durante a sessão;
navegação, componentes e renderer;
indexação ou parsing com estruturas claras e limites conhecidos;
criação de processos quando argumentos precisam permanecer separados e verificáveis.

O launcher usa C11, SDL2, SDL2_image e SDL2_ttf. A separação entre telas, componentes, núcleo de integração e UI impede que uma tela passe a controlar arquivos ou processos por conta própria.

Quando usar shell

preparar ambiente e pontos de montagem;
iniciar ou encerrar um serviço simples;
selecionar uma configuração declarativa;
executar uma sequência curta, legível e fácil de desfazer;
conectar ferramentas existentes sem transformar o script em aplicação permanente.

Quando o script passa a construir comandos a partir de texto, manter estado complexo ou analisar formatos extensos, C ou uma ferramenta dedicada oferece limites mais claros.

Boas práticas para shell

comece scripts Bash controlados com set -euo pipefail; use set -eu quando o interpretador é POSIX sh;
coloque expansões entre aspas e passe argumentos como argumentos, sem montar uma linha para eval;
use mktemp para arquivos temporários e trap para restaurar estado e remover resíduos;
declare o interpretador correto no shebang;
trate códigos de saída e escreva mensagens que indiquem a etapa que falhou;
valide com bash -n ou sh -n e ShellCheck quando disponível;
mantenha scripts de init com operações start, stop, restart e códigos coerentes.

Boas práticas para C

compile com C11, -Wall e -Wextra; módulos críticos também usam avisos mais rigorosos;
mantenha buffers e caches limitados;
confira retornos, tamanhos, posse e ciclo de vida de recursos;
prefira argv explícito a uma string de shell;
separe funções puras de I/O e processos;
use sanitizers em testes de host, sem confundir isso com prova de hardware;
teste o contrato público dos módulos, não detalhes internos frágeis.

Gates antes de integrar

O projeto combina verificação de arquitetura, testes de recursos e tema, análise de shell, build do launcher e inspeção do rootfs. O pre-push local impede que um arquivo inválido avance, mas ainda não substitui o teste no R36S, R36S Plus ou R40X Pro Max correspondente.

Uma regra simples

Se a tarefa pertence ao quadro, ao foco, ao estado da interface ou a uma sessão longa, ela tende a C. Se prepara o ambiente e termina, tende a shell. Se exige concatenação complexa de comandos ou dados não confiáveis, pare e redesenhe a fronteira.