从顺序命令到工作流:让 `.lil` 开始做判断
只要答案永远是“先 A,再 B,再 C”,线性脚本就是最合适的工具。一旦需要判断目录是否存在、复用路径、捕获结果,或带着清楚原因停止,你写的就不再只是命令列表,而是工作流。
选择刚好够用的最小自动化语言
以 #lil 开头的文件属于 Core 的线性执行方式:普通命令按顺序执行,而这种简单正是优点。它非常适合安装清单、可重复诊断和短流程。
install runhelp run变量把复制的路径变成有名字的意图
set root lil-playground 给路径一个角色。之后 $root、$source 和 $archive 直接说明这些值代表什么,而不是让你在五个位置修改同一个字面值。
好的变量名称会让脚本更易迁移。把环境特有的值集中在顶部,把敏感信息留在外面;少量清楚的变量通常比聪明的字符串拼接更可靠。
set root lil-playground
set source lil-playground/project
set archive lil-playground/project.zip条件应该保护一个假设
if dir "$source" 不是装饰:它阻止归档步骤悄悄作用在错误目标上。条件最适合保护那些一旦错误就会变得破坏性或难以理解的假设。
exists、file、empty、eq、ne、ok、fail 和 command,还可以用 not 反转。分支保持短小,让读者仍然能看懂每条路径为什么存在。
if dir "$source"
stat "$source"
else
stop "Project directory is missing"
end只有下一个决定依赖输出时才捕获
capture name <command> 执行普通 lil 命令,并把纯文本结果保存到变量。$last、$status、$cwd 和 $line 等内置变量提供常见执行状态。
不要因为可以就捕获一切。终端文本小而稳定时很合适;如果数据需要跨工具或长期保存,结构化文件或专用格式命令通常更好。
capture current pwd -s
if empty "$current"
stop "Current directory is unavailable"
end自动化之前先定义“失败”是什么意思
默认情况下 stop 让脚本可以用人能理解的原因结束。
陌生工作流第一次先用 -n。预演模式会验证并展开命令,但不执行;真正运行时再用 -v 查看完整输出。预览不是形式主义,而是让自动化始终可理解的方法。
run workflow.lil -nrun workflow.lil -v大型工作流应按职责拆分,而不是按行数拆分
工作流可以在同一变量上下文中执行
.lil 不是加密:它保护格式与完整性,避免意外编辑,但不提供保密性或作者身份保证。
run -p workflow.lil workflow.packed.lilrun workflow.packed.lil自动化刻意比交互式用户拥有更少权限
普通工作流中会阻止交互式 UI 命令,而 @command 自动安装功能在
这种摩擦是故意设计的。可复现的工作流应在执行前声明模块依赖,而不是在运行中突然安装代码、请求敏感信息,或把终端销毁。
把它保存成脚本
把它保存为 workflow.lil。如果想测试成功分支,可以创建 lil-playground/project;第一次先执行
set root lil-playground
set source lil-playground/project
set archive lil-playground/project.zip
if not dir "$root"
stop "lil-playground is missing"
end
if dir "$source"
capture current pwd -s
zip "$source" "$archive" -f
stat "$archive"
else
stop "Project directory is missing"
end