[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#27675] [PATCH] gnu: kbd: Recursively search $LOADKEYS_KEYMAP_PATH.
From: |
Tobias Geerinckx-Rice |
Subject: |
[bug#27675] [PATCH] gnu: kbd: Recursively search $LOADKEYS_KEYMAP_PATH. |
Date: |
Mon, 17 Jul 2017 13:54:48 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 |
[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
Description: OpenPGP digital signature