One more thing to add, our users use a network homedir which have no ~/.bashrc or ~/.bash_profile.  To reproduce this, you have to remove the line that has '. /etc/bashrc' from your ~/.bashrc, or remove the file entirely.

Our solution is to have the user copy over /etc/skel/.bashrc to their .bashrc.

It seems that shells started by "Open Terminal" in nautilus open a different environment than any other method of opening a Terminal.

> One more thing to add, our users use a network homedir which have no
> ~/.bashrc or ~/.bash_profile.  To reproduce this, you have to remove the
> line that has '. /etc/bashrc' from your ~/.bashrc, or remove the file
> entirely.
> 
> Our solution is to have the user copy over /etc/skel/.bashrc to their
> .bashrc.

I am a bit confused. The template at /etc/skel/.bashrc also includes /etc/bashrc. Would it be possible to have a look at a sample ~/.bashrc and ~/.bash_profile?

The drop-in scripts at /etc/profile.d are pulled in by either /etc/profile or /etc/bashrc, depending on whether the shell is a login shell or not. So, it's worth checking if the shell started from Nautilus and the shell otherwise are login shells or not. Here's one way to do that:
  $ shopt -q login_shell && echo 'Login shell' || echo 'Not login shell'

Our users start with no .bashrc or .bash_profile.  This behaviour only happens if you don't have a .bashrc or have a .bashrc that doesn't source /etc/bashrc.

Ok, I can reproduce this.

When a new GNOME Terminal is obtained via the GNOME Shell UI, the new process is forked from the gnome-shell process, which has the module() function defined in its environment. This definition is then inherited by the new terminal.

However, when a new terminal is created from inside a Nautilus window, the new process is forked from the user's instance of the dbus-daemon process (actually the nautilus process, which was forked from the user's dbus-daemon). The dbus-daemon process doesn't have the module() definition and hence it's also missing from the new terminal.

You'll notice that the module() function is also defined if a new terminal is opened from the desktop (when desktop icons are enabled). Even though the desktop icons are provided by an instance of Nautilus, that particular nautilus process is forked from gnome-shell, not the user's dbus-daemon. Hence the module() function is defined and inherited by the new terminal.

Hi,

So the session is normally started through a few wrappers, something like:

dbus-run-session -- /etc/X11/xinit/Xsession "gnome-session"

dbus-run-session ensures a session bus is started, and /etc/X11/Xsession makes a call that ensures the session is run "through" a login shell.  Something like:

→       →       exec /bin/sh -c "exec -l $SHELL -c \"$1\""

(where "$1" is interpreted to mean "gnome-session")

Note the exec -l $SHELL in the above command.  This tells the shell (pobably bash, but it depends on what the user has configured in /etc/passwd) to run
a login shell.  When the login shell is run /etc/profile.d is sourced.  But notice, this is after dbus-run-session runs and after the bus is started!

Later if the user does something that leads to a program getting started from the dbus-daemon, that process will be running under dbus-daemon's environment,
not the environment of the login shell.  Normally, this isn't that big of a deal, because gnome-session will actually forward the environment to dbus-daemon
at login time. But it can't really forward functions, just environment variables.  Again, this isn't usually a problem because ~/.bashrc sources /etc/profile.d
so any functions defined there get picked up anyway.

Changing dbus-daemon to get run within a login shell is risky. He would likely cause unintentional breakage.

Two potential workarounds:

1) instruct users to put [ -e /etc/bashrc ] && . /etc/bashrc in ~/.bashrc just as we do for the "stock" ~/.bashrc
2) there's a setting in gnome-terminal to make it always run a login shell itself, for its shell.  just tick that box in your site local configuration, or ask
users to set it the setting themselves.
3) maybe just install a script called /usr/local/bin/module that does:

#!/bin/bash

if ! declare -F module >& /dev/null; then
  [ -e /etc/profile.d/modules.sh ] || exit 1

  . /etc/profile.d/modules.sh

  declare -F module >& /dev/null || exit 1
fi

module "$@"

There is recent gnome-terminal upstream report [https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/253] where it was found that some important env variables [e.g. ssh-agent ones] are missing from the systemd --user activation environment but are present in the desktop's (gnome-shell, etc)'s environment. Is that related to/the same as this problem here?

chpe, probably different.  this is only about bash functions not environment variables.

RHEL 7 is in Maintenance Support 2 phase. We need to be very selective about the bugs we address, in order to keep the changes minimal.

Therefore, I am going to move it to RHEL 8, in the hope that we can fix it there.

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.