Re: ~/.profile and ~/.bash_profile aren't executed on login

2017-12-11 Thread Chet Ramey
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

2017-12-11 Thread Greg Wooledge
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

2017-12-11 Thread Greg Wooledge
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

2017-12-11 Thread Yuri

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

2017-12-11 Thread Chet Ramey
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

2017-12-10 Thread Geir Hauge
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

2017-12-10 Thread Yuri

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

2017-12-10 Thread Chet Ramey
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

2017-12-10 Thread Yuri

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

2017-12-10 Thread Bob Proulx
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

2017-12-10 Thread Chet Ramey
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

2017-12-09 Thread Pierre Gaston
On Sun, Dec 10, 2017 at 1:41 AM, 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.
>
> 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

2017-12-09 Thread Yuri

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

2017-12-09 Thread Chet Ramey
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

2017-12-09 Thread Yuri

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

2017-12-09 Thread Yuri

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

2017-12-09 Thread Chet Ramey
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

2017-12-09 Thread Bob Proulx
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