This is needed for konsole and yakuake in KDE too.

I'm going to do this, but it confuses me why you people just don't use login shells... /etc/profile isn't meant to be run from non-login shells

Wait a second, I'm confused. If you're not using a login shell, /etc/profile.d/ scripts shouldn't be executed. How are you executing this?

Hmmm... I have ". /etc/profile" in my .bashrc file... I guess I am doing something wrong, but /etc/profile sets a number of different values, how else should I have them set?

Use a login shell? That's the point.

How to use the login shell then?
I use KDM to login, then use yakuake. It apparently is not a login shell.
What is the login shell then?

Same here ... I log into the machine via xdm, then I open an xterm. The shell executed by xterm is not a login shell.

I know nothing of yakuake, but with xterm this can be done with either "xterm -ls" or setting xterm*loginShell: true in Xdefaults.

Alternatively, you can simply put "if [ -f /etc/bash_completion ]; then . /etc/bash_completion; fi" in your bashrc. I have it in mine because I use the same bashrc on many different platforms

Peter, are you also manually sourcing /etc/profile or something of the sort? How is it that /etc/profile.d/ scripts are getting executed in non-login shells?

Yes, I source /etc/profile in my .bashrc. Without that, I wouldn't have the system environment defined in my xterms. Arguably, I could also tell xterm to open a login shell to get the same effect, but it's not just xterm that needs to be configured accordingly. There's also Emacs M-x shell, there's remote command execution with ssh or rsh, and so on ...

Anyway, personally, I feel that profile.d/* should test for an interactive shell rather than a login shell. I realize, however, that it can be argued for the other way round just the same. It's probably a matter of personal preference.

From my understanding, bash_completion should not belong to profile.d/*.sh
Here is a attempt to explain this:
Apparently, connecting to a window manager is considered as a login into a "root" shell (such as the tty* prompts available via Ctrl+Alt+F*). This means "shopt login_shell" is on and thus /etc/profile and his family are sourced. However these "login" scripts are here to define environment stuff that can be inherit by non login "children" shell (eg Konsole, xterm, etc), such as environment variables. bash_completion does not define inheritable stuff (I think) but only change the parameters of the current bash instance (which is lost when launching a children shell). That's why it is useless to put the script in profile.d/*.sh
The right behavior should be to put the call to bash_completion in /etc/bash.bashrc (which seems to not exist in my fresh arch install but is normally sourced in non login shell) and to test the interactivity by another mean (maybe by the patch suggested in this bug report).

I tend to agree with Joel. Bash completion is inherently bash-specific, IMHO, so it does make sense to source it in /etc/bashrc instead of /etc/profile, which might be used by other bourne shell variants, too.

If we chose that path, however, we need a mechanism to make /etc/bashrc easily extendable by other packages, too, i.e. an /etc/bashrc.d/* directory. This might be the right thing to do, but it does add some complexity. Also, there might be other shells that *do* understand bash completion syntax (zsh, maybe? I hear it can do pretty much anything), and those shells might source /etc/profile but not /etc/bashrc.

I have a basic question - what is so special about profile.d, that it should only be executed by login shells?
How else am I going to get all those variables that are added by scripts in this directory, for java, firefox, alsa, locale, Qt3, wine...
Otherwise I would have to add everything to my .bashrc file, and manage those settings while applications are installed and removed.

a) The global /etc/bash.bashrc is NOT a bash default and needs to be enabled at build time. This was just done to the Arch package. Considering this, I agree that bash_completion no longer belongs in profile.d if it is in this config file.

b) @sjakub: That is the way Unix has always worked. You have one login shell that sets up all the environment, and this can spawn off multiple non-login shells that inherit that environment. If shells are not launched from a parent login shell, then they SHOULD be login shells.

If we allow /etc/profile to be run by non-login shells, we effectively remove any difference or choice for all users. That is wrong.

Script removed in bash_completion 1.0-3
The latest bash in the repos has a /etc/bash.bashrc that loads bash_completion

So how to achieve that single login shell spawning other shells in kdm? Because by default it doesn't work.

For xterm and rxvt you have edit ~/.Xdefaults:
xterm*loginShell: true
Rxvt*loginShell: true

For konsole you have to change the profile. The default command is: /bin/bash, change it to "/bin/bash -l"
In gnome-terminal you have the option to run a command as a login shell.

In other words, you have to configure every program for which you want a login shell.

I installed bash 4.0.033-1 from [testing], and /etc/bash.bashrc doesn't appear to get sourced when I start gnome-terminal as a login shell.

And then, there's this comment near the top of /etc/bash.bashrc:

> # When running a non-login shell, apply the following settings

I'm not sure what to do to have bash-completion working on a login shell. Any advice would be appreciated.

So wait... back up a second. Are you saying that /etc/bash.bashrc ISN'T sourced in a login shell?

Sigh... so that means I should put this script back, and this bug becomes a no-op.

According to http://stefaanlippens.net/bashrc_and_others only /etc/profile is sourced in login shells.

Right, /etc/profile is known. The issue is the fact that /etc/bash.bashrc is not sourced in NON-login shells.

This means the two are mutually exclusive and duplicate functionality. Sigh

Can we make /etc/profile.bash source /etc/bash.bashrc, much like how ~/.bash_profile sources $HOME/.bashrc?

Great idea. I did this in SVN. It will be in the next bash package