As the title describes. Bash (when using gnome-terminal) does not read the files in /etc/profile.d.
gnome-terminal is already configured to run the command as a login shell.
Files are read properly when using a TTY or running (in a gnome-terminal “session”)
$ sudo -i
or
$ su - username
I believe the weird behavior is related the variable $PROFILEREAD, which seems to be set on /etc/profile. But for some reason, the variable seems to be always true when gnome-terminal or xterm is run.
Btw, I understand from reading comments in /etc/profile that the preferred way for applying local configurations is via /etc/profile.local.
Your Gnome session runs a bash script on startup. And that runs “/etc/profile” which puts PROFILEREAD into your environment. This is deliberate. The idea is that these scripts should only be run once. And since that is in your environment for your entire Gnome session, it is present in any “xterm” or “gnome-terminal” that you start.
When you use “sudo” or “su -”, that clears out the environment for processes that it starts.
Maybe you should explain what you are really trying to do, but isn’t working.
The preferred way for applying local configurations **system wide **is via /etc/profile.local.
Maybe your understanding is OK, but I have seen to many people who do not see the difference of system wide profile configuration (all within /etc and configured by the system manager/administrator) and the profile additions configured by each user for her/himself in ~/.profile.
BTW, this is what the bash man page says:
When bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it first reads and executes commands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable. The --noprofile option may be used when the shell is started to inhibit this behavior. Please note that the file /etc/profile includes an autodetection shell code wether it has to source /etc/bash.bashrc as well as ~/.bashrc.
As you see there is no mentioning of /etc/profile.d, nor of /etc/profile.local. The usage of those directory and file solely depnds on code inside /etc/profile:
#
# Source profile.d files and UTF8 settings
#
# But do not source this if PROFILEREAD is already set to avoid
# overriding locale variables already present in the environment
#
if test -z "$PROFILEREAD" ; then
test -r /etc/profile.d/sh.ssh && . /etc/profile.d/sh.ssh
fi
#
# Source profile extensions for certain packages, the super
# may disable some of them by setting the sticky bit.
#
if test -d /etc/profile.d -a -z "$PROFILEREAD" ; then
for s in /etc/profile.d/*.sh ; do
test -r $s -a ! -k $s && . $s
done
unset s
fi
where you see that not all inside that directory is added.
And
if test "$is" != "ash" ; then
#
# And now let's see if there is a local profile
# (for options defined by your sysadmin, not SUSE Linux)
#
test -s /etc/profile.local && . /etc/profile.local
fi
So much of what you seem to expect depends very much on changes that might be done to /etc/profile.
Like everything else in the /etc/profile.d/ directory,
If you placed something in there, it should have worked… just the same if you placed something in /etc/profile.local or for that matter in /etc/profile(which is not recommended because your modification would be lost the next time this file is “refreshed” by openSUSE most likely in your next upgrade but possibly sooner), and also any modifications to bashrc.
You should post what you tried to place in /etc/profile.d/
My guess is that you perhaps didn’t create your file in the form of an executable script… See the other files in the directory as templates for what works.
Maybe you should explain what you are really trying to do, but isn’t working.
Simple stuff, just trying to install chruby system wide. I could use profile.local or source its snippet somewhere else and move on, but now I’m curious regarding profile.d.
Your Gnome session runs a bash script on startup. And that runs “/etc/profile” which puts PROFILEREAD into your environment. This is deliberate. The idea is that these scripts should only be run once. And since that is in your environment for your entire Gnome session, it is present in any “xterm” or “gnome-terminal” that you start.
I thought that would be the case; in fact, I had tested for that before opening this thread and have tested again now. It makes perfect sense that gnome-terminal “caches” the files deliberately.
The “problem” is that it does not run the scripts again after a cold boot. Maybe it only does so on the user’s first login? I have found nothing regarding this behavior on gnome-terminal online doc.
As you see there is no mentioning of /etc/profile.d, nor of /etc/profile.local. The usage of those directory and file solely depnds on code inside /etc/profile:
Yep, I’m aware of that. For testing purposes, I’ve placed some echos and aliases only on /etc/profile. However,
test -z $PROFILEREAD
is always false in gnome-terminal since PROFILEREAD is always true.
My guess is that you perhaps didn’t create your file in the form of an executable script… See the other files in the directory as templates for what works.
I have indeed used the others as templates, checking permissions and ownership. No files there have the +x flag. Besides, my test echos and aliases in /etc/profile are not being run either since PROFILEREAD seems to be always true. It really does seem that gnome-terminal has built its cache once and is not refreshing on startup.
Nothing is executed like a binary, but is definitely read and “run” in a matter that modifies like any entry in /etc/profile.local. But, you can’t simply place a command in /etc/profile.d/ and expect it to work like in /etc/profile.local.
I have not personally used this for Gnome-Terminal specifically, mainly for modifying system-wide environmental variables and a few experiments for starting things up on boot (mixed results, I don’t advise and there are better alternatives).
These files in /etc/profile.d/ are not executed as scripts, I only said that their format is written in that style. You shouldn’t find any with an executable bit.
As I described, your problem may be related by whatever you’re trying to do.
From your description, I’d assume you’re modifying a Gnome-Terminal environmental variable, but exactly how and what can’t be commented on without knowing exactly what you’re trying to do.
That said,
I don’t know that this are best practice modifying the internal variables of a specific app… If written correctly I assume that a system-wide modification can be made to modify a specific app (for all Users of that app)… but “It depends” on what you’re trying to do.
It should run them after a cold boot. It does that on the user login. So it runs them on graphic session startup, but won’t run them again when you start gnome-terminal.
If the user were to logout, and then login again, it should also run them at that time.
Note that the scripts are being sourced (not actually run as a separate process). And if your default shell is bash, it will only source the profile.d scripts with names ending in “.sh”. So make sure you name your script that way.
To test if your script is being sourced appropriately, have it export some funky name into the environment (say something like)
export SOME_FUNKY_NAME="hello"
And then later check in a terminal, to see if that value is in your environment.
As I described, your problem may be related by whatever you’re trying to do.
I don’t think so. Like I said before, I’m no trying to do anything fancy; just trying to understand why gnome-terminal is not picking up the change I’ve made.
Let me exemplify better. /etc/profile has this code in it:
if test -d /etc/profile.d -a -z "$PROFILEREAD" ; then
for s in /etc/profile.d/*.sh ; do
test -r $s -a ! -k $s && . $s
done
unset s
fi
This if checks whether files in /etc/profile.d should be sourced or not.
Now, for testing purposes, adding an alias:
if test -d /etc/profile.d -a -z "$PROFILEREAD" ; then
alias 'testalias'='echo hello'
for s in /etc/profile.d/*.sh ; do
test -r $s -a ! -k $s && . $s
done
unset s
fi
Again, on TTY, sudo -i and su - username all work fine.
The alias is never set on my system when using gnome-terminal. It seems that PROFILEREAD is always true, preventing the *if.
*What I want to understand is: why is PROFILEREAD true even after rebooting the system? Supposedly caching the files in profile.d in order to improve speed is a feature. At the same time, I believe that never refreshing the cache to be an anti-feature.
Correct. Because PROFILEREAD is set, your shell in gnome-terminal skips reading /etc/profile. PROFILEREAD is set because gnome-session launches login shell which sources /etc/profile and exports PROFILEREAD. All processes in your GNOME session inherit PROFILEREAD. Aliases are never exported, so any alias set by shell before launching gnome-session itself is not visible.
In general /etc/profile(.d) is wrong place to set aliases. They are expected to be present in every interactive shell, not only login shell. Default aliases are set in /etc/bash.bashrc which (as shipped by SUSE) also sources /etc/bash.bashrc.local if present. This is more appropriate place to add your aliases.
SUSE blurs distinction between profile and bashrc, but it does not mean it is good practice
It seems that PROFILEREAD is always true, preventing the if.
You have been explained multiple times that this is not true and what actually happens.
BTW -
I don’t know what your objective might be to installing and using chruby,
But you might be interested in at least taking a look at standard ways of deploying Ruby using RVM or RubyEnv…
Both are “Ruby Version Managers” which allow you to install and run multiple Ruby versions side by side on your system.
Very easy to implement after installation, you install the Ruby(s) you wish to support, then you can set the version globally, for individual projects or command line.
I see that chruby modifies paths and other environmental variables, of course a full blown Ruby version manager like RVM or Rubyenv does all that for you automatically as part of the support for multiple versions and more.
My Wiki guide (written long ago but AFAIK still valid) modifies the official RBENV setup to apply to “all Users” on your system instead of only the logged in User which can be handy… In my case awhile back I needed to to be able to both code as a normal User and with root permissions. If you don’t need that, just follow the official RBENV install guide.
Note in the chruby project page I posted that it specifically supports bash and zsh.
I assume that Gnome-Terminal can be made to work by modifying the “System Wide” entry in /etc/profiles.d/ file.
But,
I’d recommend instead that you simply install and run rbenv for the reasons I describe in my Wiki page comparing running Ruby from the OSS or RVM vs RBENV. You won’t have a problem related to whatever shell you choose.
In fact,
It looks like in a sideways manner, chruby acknowledges rvm and rbenv by describing how to “migrate” (actually simply point to existing alternative ruby manager installs) as alternatives to chruby.
I don’t use Gnome Terminal,
But took a brief look at what might be the way to modify its settings (optionally system-wide), and at least superficially could be very different than bash and zsh which could be the reason why chruby might have stopped short of supporting…
From the Gnome Terminal Wiki FAQ,
It describes various methods but all seem to be something similar to bashrc but potentially configurable globally (all users).
So,
configuring Gnome Terminal support <might> require one of the commands on this page instead of sourcing the profile to re-apply changes as described for bash and zsh.
Speculating dangerously and admittedly could be completely wrong,
TSU
Correct. Because PROFILEREAD is set, your shell in gnome-terminal skips reading /etc/profile. PROFILEREAD is set because gnome-session launches login shell which sources /etc/profile and exports PROFILEREAD. All processes in your GNOME session inherit PROFILEREAD. Aliases are never exported, so any alias set by shell before launching gnome-session itself is not visible.
Now that clears things up. I have changed my debug aliases to touchs and indeed files are created on my home folder. I still think this gnome-session optimization is an anti-feature since it kinda requires me, as a user, to know its inner working. Anyway, that’s my opinion.
I’ll adopt the other file you have mentioned then, /etc/bash.bashrc, with peace of mind.
But you might be interested in at least taking a look at standard ways of deploying Ruby using RVM or RubyEnv…
I appreciate the heads up, but I have been using RVM for a long time now and intend to migrate to chruby since it is more minimalist. I have taken a look at RBENV in the past and I think it’s kinda bloated with shims and so on. RVM gets the job done for me and has been my comfort zone for a long time now, but it also has a little bit of bloat; chruby + Bundler should be more than enough.
