Re: ~/.profile and ~/.bash_profile aren't executed on login
On 12/11/17 2:58 PM, Greg Wooledge wrote: > If the goal is ONLY to configure the environment that appears within > an interactive shell, then you can short circuit the DM/DE/WM > configuration steps and simply tell the terminal emulator to run > login shells instead of regular shells. Yes, I'm assuming this is what he wants to do. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: ~/.profile and ~/.bash_profile aren't executed on login
On Mon, Dec 11, 2017 at 01:57:52PM -0500, Chet Ramey wrote: > On 12/11/17 1:30 PM, Yuri wrote: > > /usr/local/bin/bash is set as user's login shell in 'vipw'. So when this > > user logs in, it must be invoked as a login shell. Is this correct? > > Nobody on the list can answer that question. It depends on whether or > not the agent you're using that starts the shell running in a terminal > emulator -- assuming that's the shell instance you're concerned with -- > starts it as a login shell. There are actually two issues going on here: 1) The actual login, which Yuri stated is being done through a Display Manger. 2) The invocation of an interactive shell, within a terminal emulator. If the goal is to configure the environment of the window manager and its child applications, then one must configure the login environment as set up by the Display Manager and then the desktop env or WM that it calls upon (and then possibly other layers like dbus and/or the systemd user session, especially if GNOME is involved). If the goal is ONLY to configure the environment that appears within an interactive shell, then you can short circuit the DM/DE/WM configuration steps and simply tell the terminal emulator to run login shells instead of regular shells. (Unless GNOME is involved, because GNOME is a special snowflake.) TL;DR: Ask your OS channel support people how to do whatever it is you want to do. Make sure you STATE what you want to do, because they can't be expected to guess. Be specific. Not "I want to set PATH" but "I want to set PATH to include ~/bin first because when I run my Eclipse IDE from the KDE Menu, it can't find ...". Specific.
Re: ~/.profile and ~/.bash_profile aren't executed on login
On Mon, Dec 11, 2017 at 10:30:51AM -0800, Yuri wrote: > On 12/11/17 06:03, Chet Ramey wrote: > /usr/local/bin/bash is set as user's login shell in 'vipw'. So when this > user logs in, it must be invoked as a login shell. Is this correct? No. Because you are logging in with a Display Manager, not a shell. You first need to identify WHICH Display Manager you are using. Then you need to ask your Operating System support people how to configure the login behavior of that particular DM on your particular OS. There is no consistency at all. It is done case by case.
Re: ~/.profile and ~/.bash_profile aren't executed on login
On 12/11/17 06:03, Chet Ramey wrote: Bash, as documented, reads ~/.bash_profile first when it's invoked as a login shell, falling back to ~/.bash_login and ~/.profile if it's not there. I just verified: none of these 3 files are executed by bash when user logs in. /usr/local/bin/bash is set as user's login shell in 'vipw'. So when this user logs in, it must be invoked as a login shell. Is this correct? Yuri
Re: ~/.profile and ~/.bash_profile aren't executed on login
On 12/10/17 10:22 PM, Yuri wrote: > On 12/10/17 13:51, Chet Ramey wrote: >> You have not described a bug, since you have not demonstrated that bash is >> behaving other than how it is documented, nor have you provided answers to >> any of the questions you've been asked. You haven't even determined whether >> or not bash is being invoked as a login shell at some unspecified point in >> the mystery login sequence you're using. > > > bash never calls ~/.profile when invoked as a login shell: > > > cp ~/.profile ~/.profile.bak > echo 'echo "==> executing ~/.profile"' > ~/.profile > ln -s /usr/local/bin/bash /usr/local/bin/sh > /usr/local/bin/sh --login > ==> executing ~/.profile > /usr/local/bin/bash --login > > > It only calls ~/.profile when it is named 'sh'. OK, this is progress. Bash, as documented, reads ~/.bash_profile first when it's invoked as a login shell, falling back to ~/.bash_login and ~/.profile if it's not there. When it's called with the name `sh', it reads ~/.profile. If you tried the same process with ~/.bash_profile, you would see output. This is documented in the INVOCATION section of the man page I referred to in an earlier message. > You should stop depending on sh being linked to bash. It should never > examine its name, and act as a login shell with any name. The use of `sh' to trigger reading ~/.profile is only a concession to historical compatibility -- Posix does not require it. Bash has always preferred ~/.bash_profile when invoked as a login shell. This behavior dates back to the very earliest versions. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: ~/.profile and ~/.bash_profile aren't executed on login
On Sun, Dec 10, 2017 at 07:22:36PM -0800, Yuri wrote: > It only calls ~/.profile when it is named 'sh'. In posix mode, bash only looks for ~/.profile, but when you run it in non-posix mode, it will look for ~/.bash_profile and ~/.bash_login first. You probably have a ~/.bash_profile in addition to ~/.profile. Assuming this is the case, I suggest you merge whatever it contains into ~/.profile, and remove the ~/.bash_profile file. -- Geir Hauge
Re: ~/.profile and ~/.bash_profile aren't executed on login
On 12/10/17 13:51, Chet Ramey wrote: You have not described a bug, since you have not demonstrated that bash is behaving other than how it is documented, nor have you provided answers to any of the questions you've been asked. You haven't even determined whether or not bash is being invoked as a login shell at some unspecified point in the mystery login sequence you're using. bash never calls ~/.profile when invoked as a login shell: cp ~/.profile ~/.profile.bak echo 'echo "==> executing ~/.profile"' > ~/.profile ln -s /usr/local/bin/bash /usr/local/bin/sh /usr/local/bin/sh --login ==> executing ~/.profile /usr/local/bin/bash --login It only calls ~/.profile when it is named 'sh'. Same happens when this executable is set to be user's login shell. You should stop depending on sh being linked to bash. It should never examine its name, and act as a login shell with any name. Yuri
Re: ~/.profile and ~/.bash_profile aren't executed on login
On 12/10/17 3:18 PM, Yuri wrote: > On 12/09/17 14:14, Yuri wrote: >> None of these files are executed when bash is a user's default shell on >> FreeBSD. >> No special options were selected. Despite shell.c saying that they should >> be executed they just aren't. > > > The bug is that bash doesn't handle login situation when it isn't linked to > sh. > > When I have bash as a user shell (/usr/local/bin/bash) and it isn't > redirected to sh, it fails to read ~/.profile. > > > Pleas fix this. You have not described a bug, since you have not demonstrated that bash is behaving other than how it is documented, nor have you provided answers to any of the questions you've been asked. You haven't even determined whether or not bash is being invoked as a login shell at some unspecified point in the mystery login sequence you're using. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: ~/.profile and ~/.bash_profile aren't executed on login
On 12/09/17 14:14, Yuri wrote: None of these files are executed when bash is a user's default shell on FreeBSD. No special options were selected. Despite shell.c saying that they should be executed they just aren't. The bug is that bash doesn't handle login situation when it isn't linked to sh. When I have bash as a user shell (/usr/local/bin/bash) and it isn't redirected to sh, it fails to read ~/.profile. Pleas fix this. Yuri
Re: ~/.profile and ~/.bash_profile aren't executed on login
Yuri wrote: > Bob Proulx wrote: > > How is the user logging in? Are they logging in with 'ssh' over the > > network? Or are they logging in through an "xdm" X Display Manager > > login from a graphical login display? > > User logs in locally through the display manager. Which graphical display manager? There are many. You not saying means that we are not knowing. Bob
Re: ~/.profile and ~/.bash_profile aren't executed on login
On 12/9/17 6:41 PM, Yuri wrote: > On 12/09/17 15:24, Chet Ramey wrote: >> Of course not: that's not a login shell. As the documentation says, >> >> "A login shell is one whose first character of argument zero is a -, or >> one started with the --login option." >> >> The INVOCATION section of the manual page explains it in exhaustive detail. > > > Ok, but that's not what my situation is. I am just logging in, using the > display manager, when user has /usr/local/bin/bash as the shell in passwd. Of course it's what your situation is. You're logging in, and you want some shell in the sequence (you haven't said exactly which one) to be started as a login shell and run the login shell startup files. So if you think about it logically, here's how the startup sequence probably goes: display manager authenticates the user, starts the user's window manager, window manager starts up whatever apps its startup config files specify, one of which is probably a terminal window. It's that shell (the one running in the terminal emulator) that determines whether it's a login shell -- based on the criteria listed in the man page -- and sources the appropriate startup files. > Why doesn't it execute ~/.profile? That's what you have to figure out. You have to determine why the shell that is started by the terminal emulator is not started as a login shell, if that's what you want to have happen. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: ~/.profile and ~/.bash_profile aren't executed on login
On Sun, Dec 10, 2017 at 1:41 AM, Yuriwrote: > On 12/09/17 15:24, Chet Ramey wrote: > >> Of course not: that's not a login shell. As the documentation says, >> >> "A login shell is one whose first character of argument zero is a -, or >> one started with the --login option." >> >> The INVOCATION section of the manual page explains it in exhaustive >> detail. >> > > > Ok, but that's not what my situation is. I am just logging in, using the > display manager, when user has /usr/local/bin/bash as the shell in passwd. > > Why doesn't it execute ~/.profile? > > > Yuri > > > .profile is supposed to be a file that is read only once per login, so that you can do initialization there. When you run the shell after login it doesn't read this file anymore (there are other initialization files eg .bashrc that are read every time) There is a couple of tricks coming from the history of Unix to tell a shell that it should do this initialization and these tricks are used by the programs handling the login when they start a shell. However, the way you log in to your system seems to not involve bash (or even a shell), then when you start a terminal, bash is invoked as a non-login interactive shell. You can read more there: http://mywiki.wooledge.org/DotFiles
Re: ~/.profile and ~/.bash_profile aren't executed on login
On 12/09/17 15:24, Chet Ramey wrote: Of course not: that's not a login shell. As the documentation says, "A login shell is one whose first character of argument zero is a -, or one started with the --login option." The INVOCATION section of the manual page explains it in exhaustive detail. Ok, but that's not what my situation is. I am just logging in, using the display manager, when user has /usr/local/bin/bash as the shell in passwd. Why doesn't it execute ~/.profile? Yuri
Re: ~/.profile and ~/.bash_profile aren't executed on login
On 12/9/17 6:09 PM, Yuri wrote: > On 12/09/17 15:01, Chet Ramey wrote: >> Since it doesn't happen on any other OS, I suspect an issue with either the >> FreeBSD port or the pathname that appears in argv[0] when the shell is >> started, which is what bash uses to detect that it's been invoked as a >> login shell. > > > The full path is /usr/local/bin/bash as set in passwd db. It doesn't run > ~/.profile when I run it manually using this path. Of course not: that's not a login shell. As the documentation says, "A login shell is one whose first character of argument zero is a -, or one started with the --login option." The INVOCATION section of the manual page explains it in exhaustive detail. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: ~/.profile and ~/.bash_profile aren't executed on login
On 12/09/17 15:01, Chet Ramey wrote: Since it doesn't happen on any other OS, I suspect an issue with either the FreeBSD port or the pathname that appears in argv[0] when the shell is started, which is what bash uses to detect that it's been invoked as a login shell. The full path is /usr/local/bin/bash as set in passwd db. It doesn't run ~/.profile when I run it manually using this path. Yuri
Re: ~/.profile and ~/.bash_profile aren't executed on login
On 12/09/17 14:59, Bob Proulx wrote: How is the user logging in? Are they logging in with 'ssh' over the network? Or are they logging in through an "xdm" X Display Manager login from a graphical login display? User logs in locally through the display manager. Yuri
Re: ~/.profile and ~/.bash_profile aren't executed on login
On 12/9/17 5:14 PM, Yuri wrote: > None of these files are executed when bash is a user's default shell on > FreeBSD. > No special options were selected. Despite shell.c saying that they should > be executed they just aren't. > > Is this a bug? Since it doesn't happen on any other OS, I suspect an issue with either the FreeBSD port or the pathname that appears in argv[0] when the shell is started, which is what bash uses to detect that it's been invoked as a login shell. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: ~/.profile and ~/.bash_profile aren't executed on login
Yuri wrote: > None of these files are executed when bash is a user's default shell on > FreeBSD. > No special options were selected. Despite shell.c saying that they should be > executed they just aren't. How is the user logging in? Are they logging in with 'ssh' over the network? Or are they logging in through an "xdm" X Display Manager login from a graphical login display? If from 'ssh' then that is the standard Unix login path with no surprises. If from a graphical login display, which I think most likely is the case, then it all depends upon how the shell is launched from that point. The shell looks at its own name, or the -l or --login option, to determine if it is a login shell or not. If it is a login shell then it sources the login files. If not then it does not and sources the .bashrc environment file all as documented in the manual. The most typical problem IMNHO is that graphical login managers should set things up for sourcing the login files but by default do not. I am not familiar with BSD. I am only familiar with the GNU/Linux distributions and they often fail to set things up properly to source the login files correctly. That is not a bug in bash but is a bug in the graphical login environment. This is also a case of "bike shedding" because this is something that everyone seems to have an opinion on about how this should be done. And the opinions conflict with each other. And therefore it will likely never get resolved where it works automatically without individual customization to make it work. If your environment has the capability for $HOME/.xsessionrc then that is usually the simplest suggestion to place login environment setting actions there. However note that it is a #!/bin/sh script and not a bash script and therefore should use only POSIX portable shell syntax in that file. And also note that there are many other configurations possible too. I personally do something quite different for example. Beyond this any other suggestions would require a *long* discussion of how each graphical login environment works. Therefore more information about your environment would be needed. > Is this a bug? I feel confident that it is a consequence of how the shell is started. Bob