Summary: | kde-base/konsole-4.6.2: default profile uses non-login bash shell, so /etc/profile is never sourced | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Jacob Godserv <jacobgodserv> |
Component: | [OLD] KDE | Assignee: | Gentoo KDE team <kde> |
Status: | RESOLVED INVALID | ||
Severity: | minor | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Jacob Godserv
2011-06-05 23:19:44 UTC
Yes, but normally you dont log in using konsole, right? After logging out and logging back into KDE, you should have all your settings... (In reply to comment #1) > Yes, but normally you dont log in using konsole, right? > > After logging out and logging back into KDE, you should have all your > settings... Yea, that will take care of some settings, but not all. For example, bash completion has been turned on for some time and Konsole doesn't seem to recognize that without "bash -l". I really don't like being pesky, but I think this bug is getting ignored without good reason. Perhaps you're right; Konsole shouldn't run login bash shells. In that case, this issue lies deeper than Konsole. (Perhaps KDE isn't initializing a login shell environment for KDE as a whole, and so Konsole is lacking, thus the need for "-l"? Just guessing at this point.) To see what I'm seeing, please try this: 1. Install git with bash-completion USE flag on 2. Turn on bash completion for git locally. (It shouldn't matter if it's global or local, but I use local.) 3. Open Konsole and try to run the bash function "__git_ps1". It shouldn't be found. 4. Open the profile editor and append "-l" to the shell command so bash is launched as a login shell. 5. Re-open Konsole. Run "__git_ps1", and note that it now works. 6. Removing "-l" once again from the shell command causes "__git_ps1" to not be found. I noticed that kde is different than (at least) gnome in that matter a while ago. But which behavior is correct? You can check if you have a login shell by running "shopt login_shell" I tested it using several x-terminals: konsole: login_shell off gnome-terminal: login_shell on xterm: login_shell off wterm: login_shell off So which behavior is correct? I did not check how this will look like when done in a gnome environment. (In reply to comment #4) > So which behavior is correct? This is a good question. I'd guess the correct behavior would be to have KDE itself create the correct environment, and then have Konsole inherit it. After all, I've logged into KDE, and everything inside that is using the same login session. I think I may report this upstream, if it hasn't already been done. That should provide a lot of answers. > I did not check how this will look like when done in a gnome environment. I don't understand "look like". I've always used GNOME until recently, when I decided to experiment with something new, so I might be able to answer this question. As you can see in my little experiment, it seems that not kde is special, but gnome is. As it seems to me its only gnome where you got a login shell. If you log into a gnome session, do you get a login-shell in xterm then? in konsole? in wterm or whatever other terminal app you might have installed? I for example have this in my .bashrc: # read /etc/profile if this is not a login shell if ! shopt -q login_shell && [ -r /etc/profile ]; then . /etc/profile fi (In reply to comment #6) > If you log into a gnome session, do you get a login-shell in xterm then? in > konsole? in wterm or whatever other terminal app you might have installed? Within GNOME, xterm reports: login_shell off I think the problem is within Gnome here. After all, opening a window does not constitute "logging in". If you really log out and log back in again, your environment should be ok with kde. |