GNU bug report logs - #56050
[PATCH] home: services: environment-variables: Fix XDG base directories.

Previous Next

Package: guix-patches;

Reported by: Philip McGrath <philip <at> philipmcgrath.com>

Date: Sat, 18 Jun 2022 05:26:01 UTC

Severity: normal

Tags: moreinfo, patch

Full log


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

From: "Philip McGrath" <philip <at> philipmcgrath.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 56050 <at> debbugs.gnu.org
Subject: Re: [PATCH v2 1/2] etc/guix-install.sh: Initialize XDG base
 directories.
Date: Mon, 04 Jul 2022 12:36:44 -0400
Hi,

On Mon, Jul 4, 2022, at 5:11 AM, Ludovic Courtès wrote:
> Hi!
>
> Philip McGrath <philip <at> philipmcgrath.com> skribis:
>
>> The default values from the XDG base directory specification make little
>> sense for Guix System, and some scripts in Guix assume that they are not
>> "empty or unset": for example, see <https://issues.guix.gnu.org/56050>.
>> On foreign distros, however, omitting the default values is likely to
>> break software from the distro, perhaps even preventing the desktop
>> environment from starting. To smooth over the difference, use the
>> system-wide configuration to ensure the environment variables are always
>> explicitly set on foreign distros.
>>
>> * etc/guix-install.sh (sys_create_init_profile): Explicitly initialize
>> XDG base directory variables.
>
> [...]
>
>> +# Explicitly initialize XDG base directory variables to ease compatibility
>> +# with Guix System: see <https://issues.guix.gnu.org/56050#3>.
>> +export XDG_DATA_HOME="${XDG_DATA_HOME:-$HOME/.local/share}"
>> +export XDG_CONFIG_HOME="${XDG_CONFIG_HOME:-$HOME/.config}"
>
> I think variable expansion happens at the wrong time:
>
> --8<---------------cut here---------------start------------->8---
> $ cat > /tmp/t <<EOF
>> export PATH="$PATH:foobar"
>> EOF
> $ cat /tmp/t
> export 
> PATH="/gnu/store/lq7ysaq5qbxh9xavx1zffgwrg4r8yhsy-profile/bin:/gnu/store/lq7ysaq5qbxh9xavx1zffgwrg4r8yhsy-profile/sbin:/home/ludo/.guix-home/profile/bin:/home/ludo/.guix-home/profile/sbin:/home/ludo/.guix-home/profile/bin:/home/ludo/.guix-home/profile/sbin:/run/setuid-programs:/home/ludo/.config/guix/current/bin:/home/ludo/.guix-profile/bin:/home/ludo/.guix-profile/sbin:/run/current-system/profile/bin:/run/current-system/profile/sbin:/gnu/store/0c1yfbxyv877mlgychfgvmk5ha2jqh52-gzip-1.10/bin:/gnu/store/8fpk2cja3f07xls48jfnpgrzrljpqivr-coreutils-8.32/bin:foobar"
> --8<---------------cut here---------------end--------------->8---
>
> (The problem already exists, and should be fixed, but it’s about
> variables that are less likely to be used.)
>
> Could you address that by escaping dollars?
>
> Otherwise LGTM.
>

AFAICT, this seems to work. I think this is because of a rule I didn't know about before from the section "Here Documents" under `info "(bash)Redirections"`:

> If any part of *word* is quoted, the *delimiter* is the result of
> quote removal on *word*, and the lines in the here-document
> are not expanded.

and the beginning EOF is quoted, so it works like this:

--8<---------------cut here---------------start------------->8---
$ cat quoted-here-doc.sh 
#!/bin/sh
cat <<"EOF" > out.sh
export PATH="$PATH:foobar"
EOF
$ ./quoted-here-doc.sh 
$ cat out.sh 
export PATH="$PATH:foobar"
--8<---------------cut here---------------end--------------->8---

I'm certainly no expert on shell quoting, though.

-Philip




This bug report was last modified 2 years and 165 days ago.

Previous Next


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