Le 26/06/2026 à 02:24, Koichi Murase écrivait :
I didn't carefully check `defer.c', but if the above is what is
achieved by the suggested loadable builtin, the builtin seems a very
thin wrapper of the trap builtin. The implementations by shell
functions posted by others are functionally equivalent and much
simpler than the C implementation with 195 lines.
defer here _is_ a thin wrapper, and it is even explicit upfront the
project description. Code line metrics on its own is already
questionable, but when used on languages of fundamentally different
layers, it becomes absurd.
The fork cost of subshells and the issue with the printf usage aren't
fundamental issues in implementing them with a shell function. As long
as a shell function is properly implemented, those issues shouldn't
arise. One can use no-fork command substitutions, as mentioned by
Oguz, and one can use «printf '%s\n%s' ...» or simply «"$1<newline>${
trap -P "$2"; }"», as suggested by Andreas and Gregory.
My objective is not to write a shorter script but to eliminate the
pitfalls of string manipulation in shell to manage traps.
While trap -P is a useful addition to Bash trap implementation, it
pushes the burden of a fragile command string manipulation to the shell
code. As Gregory's initial attempt abruptly illustrated, this approach
is highly error prone even for experienced users.
Deferring trap commands in a LIFO order is a dependable logic. It would
belong to core builtin. The loadable builtin here exist as a technical
demonstrator for a defer builtin proposal.
--
Léa Gris