LinuxQuestions.org - How to apply settings (.bash_profile, .bashrc, .inputrc) to all users?

- Linux - Newbie (https://www.linuxquestions.org/questions/linux-newbie-8/)

- - How to apply settings (.bash_profile, .bashrc, .inputrc) to all users? (https://www.linuxquestions.org/questions/linux-newbie-8/how-to-apply-settings-bash_profile-bashrc-inputrc-to-all-users-908198/)

How to apply settings (.bash_profile, .bashrc, .inputrc) to all users?

I've applied custom bash settings in files like .bashrc, .bash_profile, and .inputrc. However, these only apply to the current user because they're placed in the current user's home directory. I'd like apply my custom settings to all users so that I don't have to modify those files for each user. Is there any simple way to do this?

Do you have a directory, /etc/profile.d? If so, there's where you can add profile stuff that's system-wide (look at the individual shell programs in there).

Don't have /etc/profile.d? Well, you can do the old-fashioned thing and edit /etc/profile -- it runs for every log in irrespective of what shell the user is using.

Don't want to edit /etc/profile? OK, make up a shell program (and stick it /etc and make it executable) that sets things the way want them and execute it from the tail end of /etc/profile.

You can also fiddle around in the /etc/rcx.d directories, in your equivalent of rc.local (somewhere in /etc, or in the /etc/init.d directories) and do things there.

The basic thing to know is that /etc/profile is executed by every log in, always, and you can modify that file or add function to it in a separate file (invoked from /etc/profile).

Hope this helps some.

You can try to put a script into /etc/profile.d directory. All the *.sh files inside it are sourced from /etc/profile. Here is the relevant code on OpenSuSE:

Code:

#

# Source profile extensions for certain packages, the super

# user 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

Read section in the bash man page on INVOCATION. It will detail which start-up files your version of bash uses, and the order they are loaded. Modify one of those files.

In general, bashrc is for bash-specific stuff, profile is for things that could apply to all shells. The /etc directory is for system-wide configurations, and ~/ holds per-user things.

When I look at the contents of /etc/profile and /etc/bashrc, both say that rather than making changes to those files I should add scripts to /etc/profile.d/. But I thought /etc/profile (analogous to .bash_profile) is run on initial login only and /etc/bashrc (analogous to .bashrc) is run everytime a new terminal is opened. So how can both files be suggesting that I put scripts is /etc/profile.d/... When exactly will the scripts in that directory get run? Should I put things in that directory from .bash_profile or .bashrc?

Also, I see there's an /etc/inputrc - if I don't want to create a .inputrc for each user, can I simply change that file and will it be picked up by all users?

Finally, what's the point of .bashrc at all? Can't I just put everything in .bash_profile, whether it is setting environment variables, aliases, or functions? If it's set upon initial login, won't it for my whole session and all terminals opened in it? Maybe I'm just not seeing this correctly...

The file /etc/profile is executed at log in irrespective of what shell program you're using; down at the bottom of /etc/profile there should be a section that looks something like this:

Code:

# Append any additional sh scripts found in /etc/profile.d/:

for profile_script in /etc/profile.d/*.sh ; do

  if [ -x $profile_script ]; then

    . $profile_script

  fi

done

unset profile_script

This is from Slackware, yours may vary, but the essential idea is that additional settings in /etc/profile.d/*.sh files get executed to set thing specific to the shell in use plus, maybe, some other things -- and, this is important, these things are system-wide; i.e., every user logging in gets these settings in their environment. Note that everything found in /etc/profile.d that is a shell program (a .sh) and is executable (mode is 755) will get executed and there should be a test at the beginning of those files that may be shell-specific.

In my own case, I do not use BASH in favor of KornShell, so I have a /etc/profile.d/ksh.sh file that sets all KornShell user environments; however, there is not a specific BASH file in /etc/profile.d as BASH-specific settings are handled in sections of /etc/profile (at least in Slackware).

Again, all of that gets done at log in.

A user can have a .profile that overrides or augments the settings in /etc/profile and /etc/profile.d at log in. A user can also have a .bash_profile or a .bashrc file to override or augment system-wide settings. I believe that .bashrc is executed every time you hit the enter key (could be wrong about that but that's what a .cshrc file in C-shell does and system administrators sometimes use that "feature" to make sure users don't fiddle too much with their environments). A .profile covers every shell a user might use at log in, a .bash_profile is useful for user-specific aliases and the like as is a .bashrc.

Overall, if you have settings that affect every user, they really belong in /etc/profile.d so that you only have one point to maintain rather than trying to spew settings to every user account (think in terms of hundreds of users even though it may only be "you" on the box). If individual users need to have special PATH or other environment variables and other users do not, well, that's what a .profile is for in their home directories and you let them fiddle with whatever aliases they like in a .bash_profile or a .bashrc.

It's really easy to overdo this stuff and you want to keep it as simple as possible with as few maintenance points as you can. Set system-wide variables in /etc/profile.d and everybody gets 'em at log in and you don't have to deal with individual user environment problems.

Where you run into goofy stuff is with the type of terminal being used and how it is set. KDE has a terminal emulator and a Konsole (two separate utilities). You set the terminal emulator to "run command as a login shell" in the terminal emulator's preferences to get all the log in settings; Konsole just does that by default (I don't remember having to fiddle with Konsole, could be wrong).

Anyway, try to keep it as centralized and simple as possible and life will be good.

Hope this helps some.

You say to set system-wide variables in /etc/profile.d/ - what about aliases and functions? Those are supposed to go in .bashrc which is executed on every new terminal as opposed to just logins, but if I put them in /etc/profile.d/ then they'll just get executed on logins...

What about setting iptables rules on startup? If I do them in /etc/profile.d/ then these rules will get reapplied on every login. But this is a system-wide thing that should be applied once upon system startup rather than per every user login.

I would think you'd want to put individual user aliases and functions in ~/.bashrc rather than in /etc/profile.d/something.sh.

You would probably want to start up IPTABLES in /etc/rc.d/rc.local (or in whatever directory in /etc where you start daemons at system boot if not /etc/rc.d/rc.local; e.g., /etc/rcx.d). Things like IPTABLES should only start at system boot, not at user log in.

Hope this helps some.

I'm clearly getting something wrong here, because I thought /etc/profile.d/ scripts are run at user login, as you also mentioned in your responses. However, when I make a change to my script and open a new terminal window within my current login session, the changes are reflected. Meaning that my script got read! I was not expecting this, because I thought those scripts only get called on login (as for .bash_profile, but these scripts seem to be getting called at the same time as .bashrc which is for new non-login shells like opening a terminal). What's going on here then?

When you say, "open a terminal," what terminal do you mean: an xterm, konsole, terminal emulator or what? Most of those -- the exception being terminal emulator -- will open "as if you logged in." And, if you're using the terminal emulator from the system application button in the Kickoff Application Launcher (in KDE), and if the "Run application as a login shell" is selected in the preferences for terminal emulator, you'll get a log in terminal -- if that is not selected you'll get a $ prompt (no profile stuff).

Most of those "run as a login shell" by default. That's why you get all the environment settings in the newly-opened terminal.

Keep in mind that all you're doing with "extras" that you place in /etc/profile.d or in individual user .profile or .bashrc or whatever are environment settings, colors, prompt format, window size, path variables, search paths and the like. You do system-wide in /etc/profile.d/whatever and you do user-specific in ~/.profile, ~/.bashrc and the like. You do not kick off applications in those, such as IPTABLES (except in rare cases); those should get launched at boot from /etc/rc.d, /etc/rcx.d or wherever your system does those things (in other words, never from one of the profile files).

Hope this helps some.

Hi,

I agree with tronayne. For my user(s) the '~#.bash_profile' sources '~#.bashrc';

Code:

sample .bash_profile;

 ~$ cat .bash_profile



 # .bash_profile

 #08-30-06 12:21

 #

 # Source .bashrc

 if [ -f ~/.bashrc ]; then

         . ~/.bashrc

 fi

You can then have;

Code:

 sample .bashrc;

 ~$ cat .bashrc

 

 #.bashrc begin

 #08-30-06 12:20  

  

 # Add bin to path

  

 export PATH="$PATH:/sbin:/usr/sbin:$HOME/bin"

  

 #export PATH="$PATH:$HOME/bin"

  

 # Dynamic resizing

 shopt -s checkwinsize

  

 # Custom prompt

 #PS1='\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '

  

 #08-29-06 11:40

  

 if [ `id -un` = root ]; then

   PS1='\[\033[1;31m\]\h:\w\$\[\033[0m\] '

  else

   PS1='\[\033[1;32m\]\h:\w\$\[\033[0m\] '

 fi

  

 #

 # Add color

 eval `dircolors -b`

  

 # User defined aliases

 alias cls='clear'

 alias clls='clear; ls'

 alias ll='ls -l'

 alias lsa='ls -A'

 alias lsg='ls | grep'

 alias lsp='ls -1 /var/log/packages/ > package-list'

 alias na='nano'

 alias web='links -g -download-dir ~/ www.google.com'

  

 #08-29-06 11:50

  

 #To clean up and cover your tracks once you log off

 #Depending on your version of BASH, you might have to use

 # the other form of this command

   trap "rm -f ~$LOGNAME/.bash_history" 0



 #The older KSH-style form

 #  trap 0 rm -f ~$LOGNAME/.bash_history

The .bashrc is very useful!
HTH!

Quote:

Originally Posted by tronayne (Post 4507722)

Interesting, I didn't realize they mostly run as login shells. I just checked, and what I'm using is: GNOME Terminal 2.31.3, "A terminal emulator for the GNOME desktop". In the settings there's a 'Run command as login shell', which I think is what you're describing. But that option is currently not selected, which is why I'm confused that it's picking up the changes I make in /etc/profile.d/ when I open up a new tab in that terminal application. Why might that be happening?

Hi,

Quote:

excerpt from 'man bash';
INVOCATION
A login shell is one whose first character of argument zero is a -, or one started with the
--login option.

An interactive shell is one started without non-option arguments and without the -c option whose
standard input and error are both connected to terminals (as determined by isatty(3)), or one
started with the -i option. PS1 is set and $- includes i if bash is interactive, allowing a
shell script or a startup file to test this state.

The following paragraphs describe how bash executes its startup files. If any of the files exist
but cannot be read, bash reports an error. Tildes are expanded in file names as described below
under Tilde Expansion in the EXPANSION section.

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.

When bash is started non-interactively, to run a shell script, for example, it looks for the
variable BASH_ENV in the environment, expands its value if it appears there, and uses the
expanded value as the name of a file to read and execute. Bash behaves as if the following com-
mand were executed:
if [ -n "$BASH_ENV" ]; then . "$BASH_ENV"; fi
but the value of the PATH variable is not used to search for the file name.

I do suggest that you read for understanding sections of the 'man bash'.
HTH!