Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1884977 - "Open in Terminal" -> new window loses a lot of environment variables, including $HOME
Summary: "Open in Terminal" -> new window loses a lot of environment variables, includ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-terminal
Version: 33
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Matthias Clasen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1917145 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-10-04 09:00 UTC by Peter Simonyi
Modified: 2021-05-18 18:29 UTC (History)
16 users (show)

Fixed In Version: gnome-terminal-3.38.3-1.fc34 gnome-terminal-3.38.3-1.fc33
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-05-09 01:34:52 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
GNOME Gitlab GNOME/gnome-terminal - issues 303 0 None None None 2020-12-21 20:13:40 UTC

Description Peter Simonyi 2020-10-04 09:00:36 UTC 
Description of problem:
After using "Open in Terminal" from Files, new terminal windows created from that terminal run bash with several important environment variables unset, including $HOME.

Version-Release number of selected component (if applicable):
gnome-terminal-3.38.0-1.fc33.x86_64
gnome-terminal-nautilus-3.38.0-1.fc33.x86_64

How reproducible:
Always

Steps to Reproduce:
1. In Files, use "Open in Terminal" on a folder.
2. From the resulting terminal window, open a new terminal window or a new tab in the same window - Ctrl+Shift+N or Ctrl+Shift+T.

Actual results:
The shell started in step 2 is missing many environment variables that are set in the shell started in step 1.  Several of these are pretty important: $HOME, $USER, etc.

Expected results:
The environment variables in the two shells should be the same (or maybe a few small differences in values like GNOME_TERMINAL_SCREEN, but the set of keys should definitely be the same).

Additional info:
Compared to opening a fresh terminal and `cd`ing to the target directory, the shell in step 1 has these extra env variables set: G_ENABLE_DIAGNOSTIC, INVOCATION_ID, MANAGERPID, JOURNAL_STREAM.

Compared to the shell in step 1, the shell in step 2 is missing these variables:  SHELL, SESSION_MANAGER, HISTCONTROL, XDG_MENU_PREFIX, HOSTNAME, SSH_AUTH_SOCK, XMODIFIERS, DESKTOP_SESSION, LOGNAME, XDG_SESSION_DESKTOP, XDG_SESSION_TYPE, XAUTHORITY, GDM_LANG, HOME, USERNAME, XDG_CURRENT_DESKTOP=GNOME, WAYLAND_DISPLAY, G_ENABLE_DIAGNOSTIC, MANAGERPID, GNOME_SETUP_DISPLAY, XDG_SESSION_CLASS, USER, DISPLAY, QT_IM_MODULE, XDG_RUNTIME_DIR, JOURNAL_STREAM, GDMSESSION, DBUS_SESSION_BUS_ADDRESS, MAIL
Comment 1 Christian Persch 2020-10-04 09:33:19 UTC 
Upstream https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/253 and worked around in 3.38.1.
Comment 2 Peter Simonyi 2020-10-04 10:44:33 UTC 
Thanks, I'll test that as soon as there's a build, but from reading the bug reports it sounds like a different issue.

It sounds as if the problem in #253 you linked to is that the new terminal is inheriting its environment from gnome-terminal-server.  But the environment I'm getting is missing all kinds of things that are present in g-t-s's environment, like $HOME.  Check with
    cat /proc/$(ps -C gnome-terminal- -o pid:1=)/environ | tr '\0' '\n'
and see HOME, USER, HOSTNAME etc are all set.
Comment 3 Peter Simonyi 2020-10-13 13:53:56 UTC 
3.38.1 does not fix this.  Tested with:
gnome-terminal-3.38.1-1.fc33.x86_64
gnome-terminal-nautilus-3.38.1-1.fc33.x86_64

This is definitely a different issue.  Note that it also means $PATH is mangled badly: the default .bashrc adds $HOME/.local/bin and $HOME/bin to the PATH, but with HOME unset you get /.local/bin and /bin instead.  So per-user installed stuff stops working.
Comment 4 Fabio Valentini 2020-11-03 11:34:48 UTC 
Can confirm, I'm hit by this too, on fedora 33 stable.
Sometimes new gnome-terminal windows do not seem to inherit the correct / full environment.

HOME, USER, SSH_AUTH_SOCK, DESKTOP_SESSION, XDG_SESSION_DESKTOP, XDG_SESSION_TYPE, XAUTHORITY, XDG_SESSION_CLASS, DISPLAY, DBUS_SESSION_BUS_ADDRESS and others are missing (leading to problems with SSH and launching graphical applications). PATH is mangled to "/usr/lib64/ccache:/usr/local/bin:/usr/bin".
Comment 5 Sebastian Keller 2020-12-19 22:09:21 UTC 
This looks like https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/303 which has a patch linked in the comments.
Comment 6 Tadej Janež 2020-12-21 20:14:14 UTC 
(In reply to Sebastian Keller from comment #5)
> This looks like https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/303
> which has a patch linked in the comments.

The proposed patch in the upstream issue works for me.

I've created a Copr repo with the fixed version of GNOME Terminal:
https://copr.fedorainfracloud.org/coprs/tadej/gnome-terminal-f33/

I've also opened a PR so this can get included in Fedora's GNOME Terminal package:
https://src.fedoraproject.org/rpms/gnome-terminal/pull-request/4
Comment 7 Henri Hyyryläinen 2021-05-06 15:52:58 UTC 
I just updated to Fedora 34 and was very disappointed to find that the default version of gnome terminal still has this bug.
Comment 8 Fedora Update System 2021-05-07 21:48:35 UTC 
FEDORA-2021-f2f97366ff has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-f2f97366ff
Comment 9 Fedora Update System 2021-05-07 21:51:42 UTC 
FEDORA-2021-2a26a789e4 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-2a26a789e4
Comment 10 Fedora Update System 2021-05-08 02:08:07 UTC 
FEDORA-2021-2a26a789e4 has been pushed to the Fedora 33 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-2a26a789e4`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-2a26a789e4

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Comment 11 Fedora Update System 2021-05-08 02:18:31 UTC 
FEDORA-2021-f2f97366ff has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-f2f97366ff`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-f2f97366ff

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Comment 12 Fedora Update System 2021-05-09 01:34:52 UTC 
FEDORA-2021-f2f97366ff has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.
Comment 13 Fedora Update System 2021-05-11 01:15:39 UTC 
FEDORA-2021-2a26a789e4 has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.
Comment 14 Debarshi Ray 2021-05-18 18:29:20 UTC 
*** Bug 1917145 has been marked as a duplicate of this bug. ***
Note You need to log in before you can comment on or make changes to this bug.