On 2023-08-21 20:50:39, Ulrich Mueller wrote:
First, changing a low-level function like check_do() is really a no-no, because this function is documented in the eselect developer guide and third-party modules may rely on it.
The documentation, as far as I can tell, states only
check_do
The check_do utility function checks that the first parameter is a
function, and then calls it with any additional parameters as its
arguments. If the function does not exist, die is called.
Again, this is mostly internal.
The behavior here is not modified by adding the hooks. If anything the implementation ensures that if one eselect action calls another one, hooks still apply as they should.
I actually just noticed making $params a local variable works too, so that further ensures nothing in behavior changes for anything that happens to
use check_do, even if that is documented as being "mostly internal", and
not having the "PUBLIC" that for example die() has in its comment.
Calling the function with local variable "${params[@]}" instead of "$@" is
not something that's even possible to detect in bash as far as I know,
neither inside the called function nor to something calling check_do.
[...] Given that eselect modules are normally run as root and the damage that can result from bugs, I'd rather keep things simple, instead of introducing "endless" possibilities. This approach has worked very well during the last 18 years.
One of the nice things about hooks is their low profile. If you don't know about them, don't create their directory, you don't have to care. It is
not just all the possibilities of their use, it is that the price for them
is very low, for those not using them and for the maintainers of eselect.
The actions eselect does normally require root, so naturally the things a
user might want to add would too. If they used a wrapper script instead,
they would most likely run that as root too.
Second, instead of executing a separate script for every hook, there [should] be a file defining shell functions for all subactions of a
given module. But I haven't thought about any details, because as I
said, I don't see much incentive for such a thing.
I don't see any advantage to this. Spreading hooks out into their own directories is a common implementation, that allows one to have multiple independent hooks with their own version management or any other number
of differences. I have for example now split my elselect kernel set hook,
so that if I want to disable defaulting to the most recent kernel version
when no version is specified I can chmod -x
kernel/set/pre/defaultVersion while keeping the migration of .config.
From experience I usually prefer cron.hourly over an entry in cron.d
and prefer that over a line in crontab. I realize me disliking crontab is
in part because I have been burned by heavy handed distros (looking at
you synology DSM) that like to overwrite changes in configuration files,
but even a well behaved distribution like gentoo still recently migrated ssh_config and sshd_config to ssh_config.d and sshd_config.d.
I am open for arguments to the contrary but I am of the belief that a
directory approach where two independently written hooks can almost
certainly be merged on a file level without conflicts is the right
solution here and for hooks in general.
If there was, it would have been suggested previously
since eselect was created in 2005.
This isn't what eselect modules were designed for. They are specialised tools that are supposed to do one thing, and one thing only. It's like suggesting that a command like cat or mv would need configuration or
some extension mechanism.
It seems to me there might have been some drift in what eselect is.
As I have experienced it, eselect is a uniform interface to a variety of "selection decisions" that otherwise would require learning a lot of
different quirks and implementations. When you call eselect, the action
it does internally might be simple or complex, change over time, or
otherwise be annoying to manually implement yourself. What cat or mv do is predictable, uniform - eselect is not. If I want to modify what mv does (outside of its flags) I use a different command, I assemble what I
intend to do from other smaller commands because replacing mv or calling
it from somewhere else is easy.
Eselect has a certain bulk to it, which from your position I would assume
it might not have had initially. Eselect modules have accumulated a lot of quirks, specific behavior, some are truly complex looking through them now,
to the point where writing my own neither seems like something I want to do, nor like something I should. Even the eselect kernel set command has an
entire page of sanity checks and niceties.
So we have a uniform interface to a set of actions too complex to want
to do with anything else, to me this feels more like a package manager than
a posix command, eselect to me always had the same "vibe" as emerge, cron,
or init systems.
So like with emerge, if I want to change behavior I don't rewrite emerge, or what emerge does, I call it from a wrapper script. Then I have this uniform interface, where if I want some tool I write "emerge -a tool" without even thinking about it, only to then realize I forgot I should have called install_tool or emerge_tool or whatever I named the script 4 years ago
when I
wrote it. So I realize what I should have done long ago - that's right -
fork the entire tool into tool_redjard, to append my script to the install procedure, then modify emerge to see tool as tool_redjard and install my modified version. No, of course not, I use the post install hook that emerge helpfully provides me, to keep the uniform interface of my "install
everything" tool while having my hooks in a format that I can rely on
working, because I am doing it in a way the developers of emerge are aware
of.
I just remembered another reason I used the hooks approach in my case is because bash_completion still works. Those larger tools often also
accumulate external dependencies from all sides, so hooks called 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 @@
-check_do() {
+check_do() {
- local function=$1
- shift
+ local function=$1; shift
+ local params=("${@}")
if is_function "${function}" ; then
+ run_hook "${ESELECT_MODULE_NAME}" "${function##do_}" pre
- ${function} "$@"
+ ${function} "${params[@]}"
+ run_hook "${ESELECT_MODULE_NAME}" "${function##do_}" post
else
die "No function ${function}"
fi
}
+# run_hook action subaction type
+# Call optional user-provided bash files that can modify ${params[@]} +run_hook() {
+ local action=$1
+ local subaction=$2
+ local type=$3
+ for hookfile in "/etc/eselect/hooks/${action}/${subaction}/${type}"/*
; do [[
+ # run-parts checks for +x flag too, so this seems fair to me
+ -x $hookfile &&
+ # regex taken from gentoo version of run-parts
+ `basename "$hookfile"` =~ ^[a-zA-Z0-9_-][a-zA-Z0-9._-]+$
+ ]] &&
+ source "$hookfile"
+ done
+}
+
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway