GNU bug report logs - #27675
[PATCH] gnu: kbd: Recursively search $LOADKEYS_KEYMAP_PATH.

Previous Next

Full log

Message #28 received at 27675 <at> debbugs.gnu.org (full text, mbox):

From: Tobias Geerinckx-Rice <me <at> tobias.gr>
To: ludo <at> gnu.org, 27675 <at> debbugs.gnu.org
Subject: Re: [bug#27675] [PATCH] gnu: kbd: Recursively search
 $LOADKEYS_KEYMAP_PATH.
Date: Mon, 17 Jul 2017 13:54:48 +0200

[Message part 1 (text/plain, inline)]

[Sent to the list this time. Replying is hard.]

Ludo',

I don't think there's anything to ‘fix’ here.

On 17/07/17 13:00, Ludovic Courtès wrote:
> I mean, it works because it turns out that we pass those ** to Bash, 
> which does the right thing.

But that's not true:

	/* Search a list of directories and directory hierarchies */
	for (i = 0; dirpath[i]; i++) {
		recdepth = 0;
		dl       = strlen(dirpath[i]);

		/* trailing stars denote recursion */
		while (dl && dirpath[i][dl - 1] == '*')
			dl--, recdepth++;

(src/libkeymap/findfile.c:269).

> However, a search-path specification is supposed to be
> understandable internally by ‘evaluate-search-paths’

Erk. So you're saying Guix tries to do clever things (beyond separator
concatenation) to search-paths before exporting them? That won't work.
If that is the case, we'll have to use something other than search-paths
for kbd (and any packages that interpret things like ‘*’ themselves,
without a shell).

But again, at least in the installer image, LOADKEYS_KEYMAP_PATH is
properly untouched as far as I've tested.

> The ** expansion would not happen in contexts where Bash is not
> involved, which is not great.

Bash isn't involved at all in this case: "/**" is a signal to loadkeys
itself to recurse. I think that's where the confusion comes from.

Kind regards,

T G-R

[signature.asc (application/pgp-signature, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.