ed from inside
the tool is generally safer for modifying behavior than doing changes
underneath (modifying or wrapping an eselect module) or above (wrapping
the eselect command).
I'm sorry for this having gotten as long as it has
Redjard
--- a/libs/core.bash.in
+++ b/libs/core.bash.in
@@ -20,10 +20,28
params=("${@}")
if is_function "${function}" ; then
+ run_hook "${ESELECT_MODULE_NAME}" "${function##do_}" pre
- ${function} "$@"
+ ${function} "${params[@]}"
+ run_hook "${ESELECT_MODULE_NAME}
ms}"
+ run_hook "${ESELECT_MODULE_NAME}" "${function##do_}" post
else
die "No function ${function}"
fi
}
+# Redjard patch: call hooks
+run_hook() {
+ local action=$1
+ local subaction=$2
+ local hook
On 2023-08-19 06:58:10, Michał Górny wrote:
You have to provide the rationale here. You can't expect people to sign
up for some shady third-party service to read it.
My bad, not much of value is locked in the proprietary service but I
should have stated as such.
To roughly summarize, I was
From: Redjard
Add Hooks to Eselect
For example for "eselect kernel list" the script
/etc/eselect/hooks/kernel/list/pre
is called before the eselect acts, and
/etc/eselect/hooks/kernel/list/post afterwards.
In the functions you can use and modify $params, the value of which the
do
