I have a .bash_profile created that contains the environmental variables set. This was created for a particular user, say user1. I now want to reuse this environment variables also for other users, but I do not want to create yet another .bash_profile. I have a postgres user to which I would like to share this .bash_profile.
I understand that I could do this with /etc/profile. How could I reference the .bash_profile in the /etc/profile?
Copy the common content to /etc/profile. This way, it will be available for all users when they log in.
In comments I mentioned that you can modify the /etc/profile file and add the following line: source /home/<some_user>/.bash_profile. This will make this file to be sourced by all users when they log in. DO NOT DO IT: it allows a single user subverting the entire system (see comments below by trojanfoe).
Related
EDIT
The answer to my question is actually obvious, I simply forgot about the meaning of the EXPORT keyword. I still drop the explanation here, just in case.
So in a few words, when opening a terminal with Ctrl-Alt T a new shell is created, which is a child of the shell created at loggin. As explained here, the loggin shell is initialized by reading /etc/profile, and as explained here and more specifically here elements of the environment are transmitted to child processes, notably variables prefixed with the EXPORT keyword.
I am trying to understand what is the mechanism under which the PATH is set under linux when opening a new (virtual) terminal.
I know one can change the PATH in several files (e.g. system : /etc/{profile, bash.bashrc, ... } or user: ~/{.profile, .bash_login, .bashrc... }, some of which are read at login, the others when opening new (virtual) terminals.
According to my tests, it seems the "profile" files are read at startup (when the user logs in), which registers some startup values for variables such as PATH. Then, each time a terminal is opened these startup values are provided to other script (e.g. bashrc) for further configuration, resulting in something like : PATH_IN_TERMINAL=$BASHRC_ADDONS:$PATH_FROM_PROFILE
Notably, ~/.profile won't normally be read after login. Changing this file won't have any effect in the current session and the PATH_FROM_PROFILE part of the PATH will remain the same until one logs in again (after logout or through ssh connection for instance).
Am I correct ? And if so, where can I find a doc on the subject ?
Thanks
This is the best explanation I have found on the subject: Startup Files
The simple explanation, in most common situations is:
Upon initial login to host, read /etc/profile followed by the first of
~/.bash_profile, ~/.bash_login or ~/.profile. ~/.profile is
supported by multiple shells, so is preferred.
When Bash starts, but not immediately after login, read ~/.bashrc.
So, profile files are intended to run upon login and should be used to print initial messages (e.g. Security Warning, Message of the Day), check mail, and configure settings/variables that rarely change. Either system-wide (quotas, MOTD, etc.), or user-specific (timezone, locale, terminal, etc.).
.bashrc files are intended for individual users to customize their interactive experience. e.g. defining aliases, setting prompts, adding to PATH, etc.
I almost always add source ~/.bashrc to the end of my .profile file so that my shell is always customized to my requirements, even immediately after login.
NOTE: The above only applies to interactive shells (e.g. running on a terminal). None of these files are read if bash is run non-interactively (e.g. via cron). In those cases, you should create a different file containing required variables and specify that via the BASH_ENV environment file.
I have a complicated PATH that I would like to revise, and I don't understand how to do this. I cannot even figure out how a certain directory got there. Additionally, it is there twice. Is it really this hard to edit the order of a path? Is there a way to simply edit every file that determines the path?
not hard at all. The path is a colon-separated string stored in the process environment PATH variable. If you change the value of the string, your command search path will change. That's all there is to it.
PATH=/bin:/usr/bin:/usr/local/bin:$HOME/bin:.
The default path is created when you log in from a system default bashrc file in /etc and your locally configured .rc and .bashrc files. You can amend or edit PATH from inside your $HOME/.bashrc
Edit: in general, because it is so easy to change, every script included by the bashrc file, either directly or via another script, can modify the path. To know which one is making a particular change you have to track down the script.
I'm looking for a good practice there. I need to store some global config options in my node.js command-line tool.
For example typing in bash:
$: mycommand set myGlobalOption=value
and then I can use myGlobalOption with another commands, is storing this value in environment variable a good solution?
Store this in a configuration file in the user's home directory like ~/.myprog.json. You can't store persistent data in environment variables because those ultimately come from shell configuration files like ~/.bash_profile which are not machine editable. Allowing these values to be set by environment variables is reasonable, but just have the user set them herself and don't bother trying to have a set command like you describe.
You could also just take these options as command line arguments like mycommand --myglobaloption=value and let users who want to always use the same value set up a shell alias like alias mc="mycommand --myglobaloption=value".
I'm trying to set a global environment variable by adding it to the .bash_profile.
What can I do (other than restarting), to apply this value globally, so that new processes (such as Eclipse) can access this value?
Also, if my goal is adding a global environment variable, is writing it to the users' .bash_profile the best way, that doesn't require sudo?
If you add something like this to your .bash_profile:
export MY_TEST_VAR=1213222
You can then execute .bash_profile again in the current shell context
. .bash_profile
And your new processes will see this new enviroment variable
Rebooting is not necessary if it's not root's profile you modified. You just need to log off from your desktop, or close all the sessions where you want the environment refreshed.
The user's profile files is the best way to set user-specific variables.
If you want system-wide or group-wide settings, those are best left to root (for system-wide) or a restricted set of users.
You could for example implement a scheme like this: Have files like the following:
/usr/local/etc/my_group.profile
readable by all users in mygroup but writable only by users of group mygroup_admins, and make the system-wide profile script source such files depending on the user's assigned groups. This gives you a bit of flexibility without having to hand out root privileges too much.
I am writing a little install script for some software. All it does is unpack a target tar, and then i want to permanently set some environment variables - principally the location of the unpacked libs and updating $PATH. Do I need to programmatically edit the .bashrc file, adding the appropriate entries to the end for example, or is there another way? What's standard practice?
Edit: The package includes a number of run scripts (20+) that all use these named environment variables, so I need to set them somehow (the variable names have been chosen such that a collision is extremely unlikely)
LSB-compliant (see spec) practice is to create a shell script in /etc/profile.d/ folder.
Name it after your application (and make sure that the name is unique), make sure that the name ends with .sh (you might want to add scripts for other shells as well) and export the variables you need in the script. All *.sh scripts from that directory are read at user login--the same time /etc/profile is sourced.
Note that this is not enforced by bash; rather, it's an agreement of sorts.
Standard practice is to install into directories already in the path and in the standard library directory, so there is no need to update these variables.
Updating .bashrc is a bit failure-prone, among other things; what if a user uses a different file or shell?
You can also generate and install a script that sets those variables. Users of your package then source that script or copy its contents to their own shell init file.