最简repl主循环核心三步：读输入（用std::getline避免卡死）、解析执行（先trim空格再istringstream拆分）、打印结果；需检查cin.fail()、解绑cin/cout、正确处理sigint与流状态。
怎么写一个最简 REPL 主循环
核心就三步：读输入、解析执行、打印结果，再回到第一步。关键不是功能多，而是别让 std::cin 在 EOF 或中断时卡死或崩溃。
- 用
std::getline(std::cin, line)读整行，比operator>>更安全——后者遇到空格就停，还容易和后续读取错位 - 循环前加
std::cin.tie(nullptr)解绑输出流，避免每次std::cout "后强制刷新影响响应速度 - 必须检查
std::cin.fail()：用户按 Ctrl+D（Linux/macOS）或 Ctrl+Z（Windows）会触发流失效，不判断就继续循环会无限打印提示符
命令解析该不该用 std::string::find 或 sscanf
对“简易 Shell”来说，过早引入语法树或正则就是给自己挖坑。先支持空格分隔的简单命令就够了，std::string::find 和 std::string::substr 足够，但要注意边界。
- 别直接用
sscanf解析带空格的参数——它把连续空白当分隔符，但无法保留引号内空格，也难处理转义 - 用
std::istringstream拆单词更直观，但注意它跳过所有空白，无法区分ls -l /tmp和ls -l /tmp（其实你也不需要区分） - 真正容易踩的坑是忽略首尾空格：用户输
" ls -a "，得先line.erase(0, line.find_first_not_of(" \t"))再拆，否则第一个 token 是空串
执行外部命令时为什么 system() 不可靠
system() 看似省事，但它把整个字符串丢给 /bin/sh，既没法捕获 stdout/stderr，又没法获取真实退出码，还可能被注入（比如用户输 ls; rm -rf /）。
- 真要调外部命令，用
fork()+execvp()组合：先split出argv数组，最后补nullptr，再传给execvp(cmd, argv.data()) - 别忘了在子进程里调
execvp前用dup2()重定向 stdout/stderr 到父进程 pipe，否则输出直接刷到终端，你没法显示在 prompt 后面 - Windows 下没
fork，得用CreateProcessA，且argv要拼成单个字符串（遵循 MSVC 规则），引号和空格处理比 POSIX 复杂得多——简易版建议先只跑 Linux/macOS
如何让 Ctrl+C 不杀掉整个 Shell
默认情况下，Ctrl+C 发送 SIGINT 给前台进程组，你的 Shell 和它启动的子进程都会收到。你得拦截它，只让它中断当前正在跑的命令，而不是退出 Shell 本身。
立即学习“C++免费学习笔记（深入）”；
- 在主循环外用
signal(SIGINT, [](int) { /* 忽略或设标志 */ })拦住信号，但别在 signal handler 里做复杂操作（如std::cout）——它是异步信号不安全的 - 更稳妥的是用
sigaction()配合volatile sig_atomic_t g_interrupted = 0全局变量，在 handler 里只改这个变量；主循环里定期检查它，决定是否提前waitpid()并清理子进程 - 子进程启动前，记得调
signal(SIGINT, SIG_DFL)把信号行为恢复默认，否则子进程也继承了你的空 handler，Ctrl+C 就没用了
REPL 最容易被忽略的其实是信号和流状态的交叉影响：一次 Ctrl+C 可能让 std::cin 进入 failbit，接着下一行 getline 直接返回空，而你如果没清状态（std::cin.clear()），Shell 就静默卡住。这种细节没日志很难定位。
