all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Leo Prikler <leo.prikler@student.tugraz.at>
To: Chris Marusich <cmmarusich@gmail.com>
Cc: 23118@debbugs.gnu.org
Subject: bug#23118: Duplicate entries in various environment variables
Date: Thu, 03 Dec 2020 11:58:39 +0100	[thread overview]
Message-ID: <6ca9bc2b5bb96b0ea6740c3412d6aa4379d553e9.camel@student.tugraz.at> (raw)
In-Reply-To: <874mbt28k4.fsf@gmail.com>

Hello, Chris

Am Freitag, den 25.03.2016, 20:59 -0700 schrieb Chris Marusich:
> Hi,
> 
> I've noticed that my environment variables contain duplicate
> (sometimes
> more) entries.  This occurs regardless of whether the user logs in
> directly via a tty or via a desktop environment like GNOME.
> 
> [...]
> 
> As you can see, there are some environment variables with up to 9
> duplicate entries.  Is this expected?  Is it a problem?  Why is it
> happening?  Assuming that it is not expected and that it is a
> problem,
> how can we prevent it from happening?
It has been pointed out, that this is somewhat expected when wrapping
the same environment variable multiple times.  For instance, you as a
GNOME user might already have gtk+ in your GTK path if you run GNOME,
but GNOME applications can not rely on that and thus need to add their
own.  As the number of software components, that use it increases, so
does the number of mentions.  
In the special case of gnome-terminal, this is user-visible by printing
out env, but other applications get launched in a similar manner all
the time without you noticing.  Perhaps one could patch GNOME terminal
to clear those variables before spawning the shell, but that's going to
be a bit fiddly.  Alternatively, one could enforce GTK_PATH by using
"=" instead of prefix.

More generally, this can become an issue when environment variables
reach a certain size (and has led to bug reports in Guix before, which
have since been fixed).  POSIX mandates a syntax, that would allow
removing already present components first (see [1]), but I can hardly
imagine what monstrosities we would need to cook up to do this
reliably.  Not to mention, that some otherwise POSIX-compliant shells
might not implement that syntax (correctly).

Regards,
Leo

[1] 
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_02





  parent reply	other threads:[~2020-12-03 11:03 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-26  3:59 bug#23118: Duplicate entries in various environment variables Chris Marusich
2016-03-26 18:53 ` Ludovic Courtès
2016-03-28 17:53   ` Leo Famulari
2020-12-03 10:58 ` Leo Prikler [this message]
2022-10-08  1:51   ` Maxim Cournoyer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6ca9bc2b5bb96b0ea6740c3412d6aa4379d553e9.camel@student.tugraz.at \
    --to=leo.prikler@student.tugraz.at \
    --cc=23118@debbugs.gnu.org \
    --cc=cmmarusich@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.