Summary
base_std_run and base_std_exit_if_error terminate the calling process by default on failure (lib_std.sh around 1740 and 1930), while essentially every domain library function (git, gh, file, str, list, arg) returns a status code for the caller to check instead. Nothing in either function's name signals which behavior to expect.
Details
This is distinct from #284 (individual assert/validator functions inconsistently mixing return-vs-exit for the same class of caller mistake) and #287 (git/gh vs list/str/arg/cli disagreeing on exit code value, 1 vs 2, for usage errors). This issue is about the framework's two core execution primitives having an intentional, documented fail-fast default with no discoverability signal against the return-code convention every domain library otherwise follows.
A script author reading base_std_run some_cmd next to base_git_update_repo some_dir has no way to tell, from the names alone, that the first will exit their shell on failure and the second will not. This has to be learned by reading source or hitting it in production.
Impact
A script mixing both styles behaves unpredictably depending on which helper happens to fail — silent process termination from one call, a checkable return code from the next, with no naming cue to tell them apart. This is the kind of surprise that erodes trust in a "reliable shell scripting" framework's core promise.
Suggested fix
Either (a) give base_std_run a non-exiting sibling and make that the default recommended entry point in docs/examples, reserving the fail-fast variant for an explicitly-named wrapper, or (b) adopt a consistent naming/documentation signal across the whole framework (e.g. all fail-fast helpers get an explicit suffix or prefix) so the split is discoverable from the function name, not something learned by reading source.
Summary
base_std_runandbase_std_exit_if_errorterminate the calling process by default on failure (lib_std.sharound 1740 and 1930), while essentially every domain library function (git,gh,file,str,list,arg) returns a status code for the caller to check instead. Nothing in either function's name signals which behavior to expect.Details
This is distinct from #284 (individual assert/validator functions inconsistently mixing return-vs-exit for the same class of caller mistake) and #287 (git/gh vs list/str/arg/cli disagreeing on exit code value, 1 vs 2, for usage errors). This issue is about the framework's two core execution primitives having an intentional, documented fail-fast default with no discoverability signal against the return-code convention every domain library otherwise follows.
A script author reading
base_std_run some_cmdnext tobase_git_update_repo some_dirhas no way to tell, from the names alone, that the first willexittheir shell on failure and the second will not. This has to be learned by reading source or hitting it in production.Impact
A script mixing both styles behaves unpredictably depending on which helper happens to fail — silent process termination from one call, a checkable return code from the next, with no naming cue to tell them apart. This is the kind of surprise that erodes trust in a "reliable shell scripting" framework's core promise.
Suggested fix
Either (a) give
base_std_runa non-exiting sibling and make that the default recommended entry point in docs/examples, reserving the fail-fast variant for an explicitly-named wrapper, or (b) adopt a consistent naming/documentation signal across the whole framework (e.g. all fail-fast helpers get an explicit suffix or prefix) so the split is discoverable from the function name, not something learned by reading source.