2026年6月26日(金) 16:42 Léa Gris <[email protected]>: > My objective is not to write a shorter script but to eliminate the > pitfalls of string manipulation in shell to manage traps.
The users don't need to write the shell function, just the same as the users don't need to write the loadable builtin. The shell function can be provided through a shell library. Or, it can be put inside the /examples/functions instead of /examples/loadables. Currently, the contents of /examples/functions aren't installed by `make install', but I think they can be installed under `share/bash/functions/*`, etc. For the design, I'm not sure if it is robust to concatenating the trap strings by a newline. When one of the registered trap strings contains a syntax error, it would affect the subsequent commands. When one of the trap strings contains the builtin changing the control flow, such as `return', `break', and `continue`, subsequent registered trap strings would be skipped. I think the proper implementation should manage an array for each signal, which is separate from the store managed by the trap builtin. It is somewhat subjective, but another point is that I have difficulty in associating the suggested behavior with "deferring trap commands". The hooks into some of the (pseudo-)signals, such as EXIT and RETURN, may be considered as some kind of "deferring" of cleanup, etc., but, in general, we can't say (pseudo-)signals are used for deferring commands. -- Koichi
