C and shell on rogpOS

C and shell do not compete for the same space on rogpOS. C supports the long-lived, interactive path. Shell organizes short startup, assembly and operation tasks. The border is a choice of security and maintenance.

When to use C

graphical loop and real-time input;
persistent state during the session;
navigation, components and renderer;
indexing or parsing with clear structures and known limits;
creating processes when arguments need to remain separate and verifiable.

The launcher uses C11, SDL2, SDL2_image and SDL2_ttf. The separation between screens, components, integration core and UI prevents a screen from controlling files or processes on its own.

When to use shell

prepare environment and assembly points;
start or end a simple service;
select a declarative configuration;
execute a short, readable, and easy-to-undo sequence;
connect existing tools without turning the script into a permanent application.

When the script moves on to constructing commands from text, maintaining complex state, or parsing large formats, C or a dedicated tool provides clearer boundaries.

Shell best practices

start controlled Bash scripts with set -euo pipefail; use set -eu when the interpreter is POSIX sh;
enclose expansions in quotation marks and pass arguments as arguments, without putting together a line to eval;
use mktemp for temporary files and trap to restore condition and remove waste;
declare the correct interpreter in the shebang;
handle exit codes and write messages that indicate the step that failed;
validate with bash -n or sh -n and ShellCheck when available;
maintain init scripts with operations start, stop, restart and coherent codes.

Good practices for C

compile with C11, -Wall and -Wextra; critical modules also use stricter warnings;
keep buffers and caches limited;
check returns, sizes, ownership and life cycle of resources;
prefer argv explicit to a shell string;
separate pure I/O functions and processes;
use sanitizers in host tests, without confusing this with hardware testing;
test the public contract of modules, not fragile internal details.

Gates before integrating

The project combines architecture verification, feature and theme testing, shell analysis, launcher build, and rootfs inspection. Local pre-push prevents an invalid file from moving forward, but still does not replace testing on the corresponding R36S, R36S Plus, or R40X Pro Max.

A simple rule

If the task belongs to the frame, focus, interface state, or a long session, it tends to C. If it prepares the environment and finishes, it tends to shell. If it requires complex concatenation of commands or unreliable data, stop and redraw the boundary.