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

Previous Next

Full log

View this message in rfc822 format

From: ludo <at> gnu.org (Ludovic Courtès)
To: Tobias Geerinckx-Rice <me <at> tobias.gr>
Cc: 27675 <at> debbugs.gnu.org
Subject: [bug#27675] [PATCH] gnu: kbd: Recursively search $LOADKEYS_KEYMAP_PATH.
Date: Mon, 17 Jul 2017 13:00:51 +0200

Heya,

Tobias Geerinckx-Rice <me <at> tobias.gr> skribis:

> On 17/07/17 11:20, Ludovic Courtès wrote:
>> Tobias Geerinckx-Rice <me <at> tobias.gr> skribis:
>> 
>>> Fix a regression since commit fd7000fe33d3c4188c241cab97e2b891dd4e1268.
>
> <snip>
>
>> That works if you copy paste the suggested search path in a shell, but
>> not if we pass it to ‘evaluate-search-paths’ from (guix search-paths)
>
> I'm confused. What exactly doesn't work? Here, after this patch,
> LOADKEYS_KEYMAP_PATH contains "**" like it should.

I mean, it works because it turns out that we pass those ** to Bash,
which does the right thing.

However, a search-path specification is supposed to be understandable
internally by ‘evaluate-search-paths’ (this is what is used in build
environments, when generating ‘etc/profile’, when using --search-paths,
and so on.)  The ** expansion would not happen in contexts where Bash is
not involved, which is not great.

In this case I agree that it’s almost a theoretical problem because in
practice, for LOADKEYS_KEYMAP_PATH, we’re always passing the search path
to the shell.  So maybe it’s not worth fixing after all, dunno.  WDYT?

Ludo’.

Previous Next

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