I'm trying to set environment variables for non-interactive non-login shell. I know bash reads the contents of ~/.bashrc before execute the command. In the beginning of the script there's a part:
*# If not running interactively, don't do anything
case $- in
*i*) ;;
*) return;;
esac*
So I think if I add something above it, it will take effect no matter if the shell is interactive or not:
export VAR=something
# If not running interactively, don't do anything
case $- in
*i*) ;;
*) return;;
esac
However it doesn't work :(. I want to avoid using $BASH_ENV because it messes up my xkb settings. I remapped some keys in /usr/share/X11/xkb/symbols/pc. And if I set $BASH_ENV, it will just loads the default keymap.
Solution for Ubuntu: set the variables in /etc/environment, and it works for all users and all types of shells.
The details are somewhat platform-dependent. Bash Startup Files in the reference manual describes the default behavior of Bash itself; but you also need to take into account the behavior of your particular platform.
In general, $HOME/.bashrc is executed for non-interactive login shells, but no script can be guaranteed to run for a non-interactive non-login shell. You can force it by setting (and exporting!) BASH_ENV from a parent shell to the name of a script which you want to execute when a non-interactive shell is started.
Sometimes, an acceptable workaround is to run a script in a login shell, and trust that the non-interactive non-login script you run inherits whatever parameters you set in the login shell. This is what e.g. /etc/environment can do; but it does not force a piece of script to run at the time when a noninteractive shell is subsequently started (except of course if you use /etc/environment to set up BASH_ENV as described above).
Related
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
What's the difference between .bashrc, .bash_profile, and .environment?
It seems that if I use
alias ls='ls -F'
inside of .bashrc on Mac OS X, then the newly created shell will not have that alias. I need to type bash again and that alias will be in effect.
And if I log into Linux on the hosting company, the .bashrc file has a comment line that says:
For non-login shell
and the .bash_profile file has a comment that says
for login shell
So where should aliases be written in? How come we separate the login shell and non-login shell?
Some webpage say use .bash_aliases, but it doesn't work on Mac OS X, it seems.
The reason you separate the login and non-login shell is because the .bashrc file is reloaded every time you start a new copy of Bash. The .profile file is loaded only when you either log in or use the appropriate flag to tell Bash to act as a login shell.
Personally,
I put my PATH setup into a .profile file (because I sometimes use other shells);
I put my Bash aliases and functions into my .bashrc file;
I put this
#!/bin/bash
#
# CRM .bash_profile Time-stamp: "2008-12-07 19:42"
#
# echo "Loading ${HOME}/.bash_profile"
source ~/.profile # get my PATH setup
source ~/.bashrc # get my Bash aliases
in my .bash_profile file.
Oh, and the reason you need to type bash again to get the new alias is that Bash loads your .bashrc file when it starts but it doesn't reload it unless you tell it to. You can reload the .bashrc file (and not need a second shell) by typing
source ~/.bashrc
which loads the .bashrc file as if you had typed the commands directly to Bash.
Check out http://mywiki.wooledge.org/DotFiles for an excellent resource on the topic aside from man bash.
Summary:
You only log in once, and that's when ~/.bash_profile or ~/.profile is read and executed. Since everything you run from your login shell inherits the login shell's environment, you should put all your environment variables in there. Like LESS, PATH, MANPATH, LC_*, ... For an example, see: My .profile
Once you log in, you can run several more shells. Imagine logging in, running X, and in X starting a few terminals with bash shells. That means your login shell started X, which inherited your login shell's environment variables, which started your terminals, which started your non-login bash shells. Your environment variables were passed along in the whole chain, so your non-login shells don't need to load them anymore. Non-login shells only execute ~/.bashrc, not /.profile or ~/.bash_profile, for this exact reason, so in there define everything that only applies to bash. That's functions, aliases, bash-only variables like HISTSIZE (this is not an environment variable, don't export it!), shell options with set and shopt, etc. For an example, see: My .bashrc
Now, as part of UNIX peculiarity, a login-shell does NOT execute ~/.bashrc but only ~/.profile or ~/.bash_profile, so you should source that one manually from the latter. You'll see me do that in my ~/.profile too: source ~/.bashrc.
From the bash manpage:
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.
When a login shell exits, bash
reads and executes commands from the
file ~/.bash_logout, if it exists.
When an interactive shell that is not a login shell is started, bash
reads and executes commands from ~/.bashrc, if that file exists. This
may be inhibited by using the --norc option. The --rcfile file option
will force bash to read and execute commands from file instead of
~/.bashrc.
Thus, if you want to get the same behavior for both login shells and interactive non-login shells, you should put all of your commands in either .bashrc or .bash_profile, and then have the other file source the first one.
.bash_profile is loaded for a "login shell". I am not sure what that would be on OS X, but on Linux that is either X11 or a virtual terminal.
.bashrc is loaded every time you run Bash. That is where you should put stuff you want loaded whenever you open a new Terminal.app window.
I personally put everything in .bashrc so that I don't have to restart the application for changes to take effect.
I need to change the greeting of user, which is logging in. So I modifyed file /etc/profile. In this greeting I need to know, which shell this user use and tell it to user. The problem is that then I change my shell on zsh or csh it doesnt work. Even if I just type in this file echo $SHELL it do nothing. As I think, when I use csh and zsh this file (/etc/profile) doesnt run at all. How can I fix this problem?
Thanks you, sorry for my English)
You should start by reading the manpage of every shell on your system.
There are different flavours of shells. Each flavours uses slightly different (per session and per shell, per site and per user) initialisation files. For example:
sh (and bash) use /etc/profile and ~/.profile
bash also uses ~/.bash_profile, ~/.bashrc, ~/.bash_logout
csh uses /etc/.login and ~/.cshrc
etc...
The above list is not meant to be exhaustive. It is to illustrate you will need to check the exact behaviour of each shell that is used on your system and configure it appropriately.
You also need to consider whether you want to change system-wide behaviour (corresponding to initialisation files under /etc) or user-specific behaviour (corresponding to initialisation files in the user's home directory).
For certain shells, there's also per-session (i.e. once per login) and per-shell settings (e.g. for every terminal window). A good example is ~/.bash_login (executed once per login) and ~/.bashrc (executed for every shell - e.g. terminal window).
They both execute different files:
From fro zsh http://zsh.sourceforge.net/Guide/zshguide02.html
Now here's a list of the startup files and when they're run. You'll
see they fall into two classes: those in the /etc directory, which are
put there by the system administrator and are run for all users, and
those in your home directory, which zsh, like many shells, allows you
to abbreviate to a `~'.
/etc/zshenv
Always run for every zsh.
~/.zshenv
Usually run for every zsh (see below).
/etc/zprofile
Run for login shells.
~/.zprofile
Run for login shells.
/etc/zshrc
Run for interactive shells.
~/.zshrc
Run for interactive shells.
/etc/zlogin
Run for login shells.
~/.zlogin
for csh http://unixhelp.ed.ac.uk/CGI/man-cgi?csh+1
A login shell begins by executing commands from the system files
/etc/csh.cshrc and /etc/csh.login.
You can make a soft link to point to the same file:
ln -s /etc/profile /etc/zshenv
ln -s /etc/profile /etc/csh.login
I have modified my etc/profile file to start a python script on startup. now my program is running but there is a black screen, because my program has a while True loop in it and now I am not able to stop it. Kindly tell me how to stop the program, I have tried ctrl+C but nothing happened.
I'm using the Fedora 20 graphical desktop. I found the alias put in the .bash_profile didn't have effect. Then I find the graphical terminal is not a login shell, so the bash_profile is not read at all.
Now it's weird to me that the export command does have effect in .bash_profile.
My .bash_profile is as below:
#bash_profile
export mytest=bash_profileIsRead
alias kk=ls
Test result:
$ shopt login_shell
login_shell off
$ echo $mytest
bash_profileIsRead
$ kk
bash: kk: command not found...
There's nothing unusual or surprising about this.
Your .bash_profile is run once per session, by your login shell. It is not run by other shells run later in your session.
.bashrc, by contrast, is run by every interactive shell instance, so things like aliases and shell functions placed there will be honored throughout the session.
Environment variables only need to be set once, because they're inherited by subprocesses (every subprocess, not just shells!). Aliases are not inherited, so they need to be set in every shell.
See the DotFiles page on the wooledge.org wiki (maintained by irc.freenode.org's #bash channel) for more.
Aliases are not inherited like environment variables. They should not be placed in profile, but instead in the .bashrc file.
Basically, .profile (or .bash_profile) is for things that are inherited (e.g. env variables) and the rc file is for things that must be re-initialized in non-login shells, such as aliases.
I am currently looking for a way to set enviroment variables in Linux via a simple shell script. Within the script I am currently using the 'export' command, however this only has scope within the script where system-wide scope is needed.
Is there anyway I can do this via a shell script, or will another method need to be used?
When you run a shell script, it executes in a sub-shell. What you need is to execute it in the context of the current shell, by sourcing it with:
source myshell.sh
or:
. myshell.sh
The latter is my preferred approach since I'm inherently lazy.
If you're talking about system-wide scope inasmuch as you want to affect everybody, you'll need to put your commands in a place where they're sourced at login time (or shell creation time), /etc/profile for example. Where you put your commands depends on the shell being used.
You can find out what scripts get executed by examining the man page for your shell:
man bash
The bash shell, when invoked as a login shell (including as a non-login shell but with the --login parameter), will use /etc/profile and the first of ~/.bash_profile, ~/.bash_login or ~/.profile.
Non-login bash shells will use. unless invoked with --norc or --rcfile <filename>, the files /etc/bash.bashrc and ~/.bashrc.
I'm pretty certain it's even more convoluted than that depending on how the shell is run, but that's as far as my memory stretches. The man page should detail it all.
You could have your script check for the existence of something like /var/myprog/env-vars-to-load and 'source' it then unlink it if it exists, perhaps using trap and a signal. Its hard to say, I'm not familiar with your program.
There is no way to 'inject' environmental variables into another process' address space, so you'll have to find some method of IPC which will can instruct the process on what to set.
A fundamental aspect of environment variables is that you cannot affect the environment for any process but your own and child processes that you spawn. You can't create a script that sets "system wide" environment variables that somehow become usable by other processes.
On the shell prompt:
$ source script.sh
And set the env vars in script.sh
test.sh
#!/bin/bash
echo "export MY_VAR=STACK_OVERFLOW" >> $HOME/.bashrc
. $HOME/.bashrc
sh task.sh
task.sh
#!/bin/sh
echo $MY_VAR
Add executable rights:
chmod +x test.sh task.sh
And lauch test.sh
./test.sh
Result:
STACK_OVERFLOW
Can I have certain settings that are universal for all my users?
As well as /etc/profile which others have mentioned, some Linux systems now use a directory /etc/profile.d/; any .sh files in there will be sourced by /etc/profile. It's slightly neater to keep your custom environment stuff in these files than to just edit /etc/profile.
If your LinuxOS has this file:
/etc/environment
You can use it to permanently set environmental variables for all users.
Extracted from: http://www.sysadmit.com/2016/04/linux-variables-de-entorno-permanentes.html
man 8 pam_env
man 5 pam_env.conf
If all login services use PAM, and all login services have session required pam_env.so in their respective /etc/pam.d/* configuration files, then all login sessions will have some environment variables set as specified in pam_env's configuration file.
On most modern Linux distributions, this is all there by default -- just add your desired global environment variables to /etc/security/pam_env.conf.
This works regardless of the user's shell, and works for graphical logins too (if xdm/kdm/gdm/entrance/… is set up like this).
Amazingly, Unix and Linux do not actually have a place to set global environment variables. The best you can do is arrange for any specific shell to have a site-specific initialization.
If you put it in /etc/profile, that will take care of things for most posix-compatible shell users. This is probably "good enough" for non-critical purposes.
But anyone with a csh or tcsh shell won't see it, and I don't believe csh has a global initialization file.
Some interesting excerpts from the bash manpage:
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.
...
When an
interactive shell that is not a login
shell is started, bash reads and
executes commands from
/etc/bash.bashrc and ~/.bashrc, if
these files exist. This may be
inhibited by using the --norc option.
The --rcfile file option will force
bash to read and execute commands from
file instead of /etc/bash.bashrc and
~/.bashrc.
So have a look at /etc/profile or /etc/bash.bashrc, these files are the right places for global settings. Put something like this in them to set up an environement variable:
export MY_VAR=xxx
Every process running under the Linux kernel receives its own, unique environment that it inherits from its parent. In this case, the parent will be either a shell itself (spawning a sub shell), or the 'login' program (on a typical system).
As each process' environment is protected, there is no way to 'inject' an environmental variable to every running process, so even if you modify the default shell .rc / profile, it won't go into effect until each process exits and reloads its start up settings.
Look in /etc/ to modify the default start up variables for any particular shell. Just realize that users can (and often do) change them in their individual settings.
Unix is designed to obey the user, within limits.
NB: Bash is not the only shell on your system. Pay careful attention to what the /bin/sh symbolic link actually points to. On many systems, this could actually be dash which is (by default, with no special invocation) POSIXLY correct. Therefore, you should take care to modify both defaults, or scripts that start with /bin/sh will not inherit your global defaults. Similarly, take care to avoid syntax that only bash understands when editing both, aka avoiding bashisms.
Using PAM is execellent.
# modify the display PAM
$ cat /etc/security/pam_env.conf
# BEFORE: $ export DISPLAY=:0.0 && python /var/tmp/myproject/click.py &
# AFTER : $ python $abc/click.py &
DISPLAY DEFAULT=${REMOTEHOST}:0.0 OVERRIDE=${DISPLAY}
abc DEFAULT=/var/tmp/myproject