public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
* [gentoo-dev] Re: Add Hooks to Eselect
  2023-08-18 19:38 ` [gentoo-dev] " Redjard
@ 2023-08-21  0:15   ` Duncan
  2023-08-21 17:50     ` konsolebox
  0 siblings, 1 reply; 3+ messages in thread
From: Duncan @ 2023-08-21  0:15 UTC (permalink / raw
  To: gentoo-dev

Redjard posted on Fri, 18 Aug 2023 21:38:37 +0200 as excerpted:

> From: Redjard <eselect.patches.gentoo@redjard.org>
> 
> 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.

Suggestion: A more flexible approach would make pre/post directories, such 
that "any" file therein (exceptions for backups, etc) would be sourced.

In run_hook something like (as written assumes bashisms OK, didn't verify 
if that's valid for eselect or not):

local action=$1
local subaction=$2
local hookscriptdir=$3

for $hookfile in
	/etc/eselect/hooks/${action}/${subaction}/${hookscriptdir}/*
do [[
		# maybe skip either the executable or README test?
		# or perhaps only match *.sh filenames instead
		# to reflect the in-shell sourcing?
		-x $hookfile &&
		$hookfile == ${hookfile#README} &&
		$hookfile == ${hookfile#.} &&
		$hookfile == ${hookfile%.bak} &&
		$hookfile == ${hookfile%\~}
	]] && source "$hookfile"
done


-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman



^ permalink raw reply	[flat|nested] 3+ messages in thread

* [gentoo-dev] Re: Add Hooks to Eselect
@ 2023-08-21 10:19 Redjard
  0 siblings, 0 replies; 3+ messages in thread
From: Redjard @ 2023-08-21 10:19 UTC (permalink / raw
  To: gentoo-dev


On 2023-08-21 02:15:08, Duncan wrote:
> Suggestion: A more flexible approach would make pre/post directories, such 
> that "any" file therein (exceptions for backups, etc) would be sourced.
>
> In run_hook something like (as written assumes bashisms OK, didn't verify 
> if that's valid for eselect or not):
>
> local action=$1
> local subaction=$2
> local hookscriptdir=$3
>
> for $hookfile in
> 	/etc/eselect/hooks/${action}/${subaction}/${hookscriptdir}/*
> do [[
> 		# maybe skip either the executable or README test?
> 		# or perhaps only match *.sh filenames instead
> 		# to reflect the in-shell sourcing?
> 		-x $hookfile &&
> 		$hookfile == ${hookfile#README} &&
> 		$hookfile == ${hookfile#.} &&
> 		$hookfile == ${hookfile%.bak} &&
> 		$hookfile == ${hookfile%\~}
> 	]] && source "$hookfile"
> done

eselect as a whole is a bash-script, so bashisms should indeed be ok.
I agree that a directory as the last level is the right choice for a
system the user didn't write themselves.
The filename requirements didn't seem right to me, so I dug through the 
source
of run-parts in sys-apps/debianutils and found the default behavior as
> regcomp(&classicalre, "^[a-zA-Z0-9_-][a-zA-Z0-9._-]+$",REG_EXTENDED | REG_NOSUB)
which curiously appears to be different from upstream "^[a-zA-Z0-9_-]+$",
which would not match script.sh for example.
Using the gentoo behavior of run-parts seems like the least 
controversial implementation to me.
An executable check seems unnecessary, the directory is clearly marked 
as containing hooks.

--- a/libs/core.bash.in
+++ b/libs/core.bash.in
@@ -20,10 +20,24 @@
-check_do() {
+check_do() {
  	local function=$1
-	shift
+	shift; params="$@"
  	if is_function "${function}" ; then
-		${function} "$@"
+		run_hook "${ESELECT_MODULE_NAME}" "${function##do_}" pre
+		${function} "${params}"
+		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 hookscriptdir=$3
+	for hookfile in 
"/etc/eselect/hooks/${action}/${subaction}/${hookscriptdir}"/* ; do [[
+		`basename "$hookfile"` =~ ^[a-zA-Z0-9_-][a-zA-Z0-9._-]+$
+	]] &&
+		source "$hookfile"
+	done
+}
+


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [gentoo-dev] Re: Add Hooks to Eselect
  2023-08-21  0:15   ` [gentoo-dev] " Duncan
@ 2023-08-21 17:50     ` konsolebox
  0 siblings, 0 replies; 3+ messages in thread
From: konsolebox @ 2023-08-21 17:50 UTC (permalink / raw
  To: gentoo-dev

[-- Attachment #1: Type: text/plain, Size: 730 bytes --]

On Mon, Aug 21, 2023, 08:15 Duncan, <1i5t5.duncan@cox.net> wrote:

> Suggestion: A more flexible approach would make pre/post directories,
>

Or allow both file and directories.


> do [[
>                 # maybe skip either the executable or README test?
>                 # or perhaps only match *.sh filenames instead
>                 # to reflect the in-shell sourcing?
>                 -x $hookfile &&
>                 $hookfile == ${hookfile#README} &&
>                 $hookfile == ${hookfile#.} &&
>                 $hookfile == ${hookfile%.bak} &&
>                 $hookfile == ${hookfile%\~}
>         ]] && source "$hookfile"
> done
>

Just checking if file has +x is better.  Easier to disable scripts that
way.

[-- Attachment #2: Type: text/html, Size: 1460 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2023-08-21 17:50 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-08-21 10:19 [gentoo-dev] Re: Add Hooks to Eselect Redjard
     [not found] <840371d1-21b3-f71b-03e0-0ef5b5ca2059@julianahl.de>
2023-08-18 19:38 ` [gentoo-dev] " Redjard
2023-08-21  0:15   ` [gentoo-dev] " Duncan
2023-08-21 17:50     ` konsolebox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox