Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #276011 > unrolled thread

bashrc question

Back to article view | Back to linux.debian.user

Contents

  bashrc question henrik@privatembox.com - 2024-12-26 04:40 +0100
    Re: bashrc question George at Clug <Clug@goproject.info> - 2024-12-26 04:50 +0100
    Re: bashrc question Greg Wooledge <greg@wooledge.org> - 2024-12-26 05:00 +0100
      Re: bashrc question henrik@privatembox.com - 2024-12-26 09:30 +0100
        Re: bashrc question Chris Green <cl@isbd.net> - 2024-12-26 12:20 +0100
          Re: bashrc question pocket@homemail.com - 2024-12-26 14:00 +0100
          Re: bashrc question Greg Wooledge <greg@wooledge.org> - 2024-12-26 14:10 +0100
            Re: bashrc question henrik@privatembox.com - 2024-12-27 01:10 +0100
    Re: bashrc question Frank Jezzer <etphonehomefrance@gmail.com> - 2024-12-26 17:00 +0100

#276011 — bashrc question

Hello

I have these settings in .bashrc of my home dir:

$ cat .bashrc
export TF_CPP_MIN_LOG_LEVEL=3
export CUDA_VISIBLE_DEVICES=-1

but every time after i login the system, the settings are not activated.
I have to source it by hand to make it work.

what's wrong with me?

Thanks.

[toc] | [next] | [standalone]

#276012

On Thursday, 26-12-2024 at 14:16 henrik@privatembox.com wrote:
> Hello
> 
> I have these settings in .bashrc of my home dir:
> 
> $ cat .bashrc
> export TF_CPP_MIN_LOG_LEVEL=3
> export CUDA_VISIBLE_DEVICES=-1
> 
> but every time after i login the system, the settings are not activated.
> I have to source it by hand to make it work.

As long as you only need these settings to apply to you user session:

$ nano ~./bashrc

(add the following lines to the end of file, and save )

# My specific settings 202412
export TF_CPP_MIN_LOG_LEVEL=3
export CUDA_VISIBLE_DEVICES=-1

Save and exit your editor, then the next time you log in, these settings will be applied to your session.

(does this do what you want?)

> 
> what's wrong with me?
> 
> Thanks.
> 
> 

[toc] | [prev] | [next] | [standalone]

#276013

On Thu, Dec 26, 2024 at 04:16:17 +0100, henrik@privatembox.com wrote:
> Hello
> 
> I have these settings in .bashrc of my home dir:
> 
> $ cat .bashrc
> export TF_CPP_MIN_LOG_LEVEL=3
> export CUDA_VISIBLE_DEVICES=-1
> 
> but every time after i login the system, the settings are not activated.
> I have to source it by hand to make it work.
> 
> what's wrong with me?

1) What shell do you use?
2) How do you get to a terminal?

If you're not using bash as your login shell, then it makes perfect
sense .bashrc wouldn't be read.

If you open a terminal which works *normally*, it should run a non-login
shell, which in the case of bash should read .bashrc.

However, if your terminal has been configured to run a login shell,
then it will read .bash_profile or .bash_login or .profile instead.

However however, your .profile or equivalent should be configured to
dot in your .bashrc file, possibly after verifying that you are, in
fact, in bash.

A .profile which fails to dot in .bashrc will lead you to all kinds of
subtle problems whenever you launch a login shell, which would normally
be when you ssh in, or login on a text console.

A terminal emulator should normally run a NON-login shell, but some of
them are sometimes configured to do the wrong thing because it works
around stupid users.  So, if you're using a Desktop Environment that
assumes you are a stupid user, it might be running your shell as a login
shell.

You can tell whether your shell is a login shell by looking at the
name it's invoked with (via ps(1) or similar commands).  If the
invocation name begins with a hyphen ("-"), it's a login shell.


hobbit:~$ ssh localhost
greg@localhost's password: 
Linux hobbit 6.1.0-28-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.119-1 (2024-11-22) x86_64
[...]
hobbit:~$ ps -fp $$
UID          PID    PPID  C STIME TTY          TIME CMD
greg     1001894 1001893  0 22:46 pts/29   00:00:00 -bash


That's a login shell, because I ssh'ed in.  You can tell because it's
invoked as "-bash" instead of "bash".  As a login shell, it will read
my .profile, and my .profile contains:


hobbit:~$ grep bashrc .profile
. ./.bashrc


so that my .bashrc file is *also* read.  Yours should have this too,
or something fancier, maybe even

    test "$BASH" && source ~/.bashrc

or the default Debian /etc/skel/.profile way:

    # if running bash
    if [ -n "$BASH_VERSION" ]; then
	# include .bashrc if it exists
	if [ -f "$HOME/.bashrc" ]; then
	    . "$HOME/.bashrc"
	fi
    fi

which is ridiculously verbose.  I went with a more basic route.

[toc] | [prev] | [next] | [standalone]

#276015

On 26.12.2024 04:52, Greg Wooledge wrote:
> On Thu, Dec 26, 2024 at 04:16:17 +0100, henrik@privatembox.com wrote:
>> Hello
>> 
>> I have these settings in .bashrc of my home dir:
>> 
>> $ cat .bashrc
>> export TF_CPP_MIN_LOG_LEVEL=3
>> export CUDA_VISIBLE_DEVICES=-1
>> 
>> but every time after i login the system, the settings are not 
>> activated.
>> I have to source it by hand to make it work.
>> 
>> what's wrong with me?
> 
> 1) What shell do you use?

Hi Greg,

The shell i am using is bash.
$ echo $SHELL
/bin/bash



> 2) How do you get to a terminal?

Just ssh to remote host to get a terminal. My ssh client is in Mac's 
terminal.

> 
> If you're not using bash as your login shell, then it makes perfect
> sense .bashrc wouldn't be read.
> 
> If you open a terminal which works *normally*, it should run a 
> non-login
> shell, which in the case of bash should read .bashrc.


what's non-login shell and login shell? i am not sure about this.


> 
> However, if your terminal has been configured to run a login shell,
> then it will read .bash_profile or .bash_login or .profile instead.
> 
> However however, your .profile or equivalent should be configured to
> dot in your .bashrc file, possibly after verifying that you are, in
> fact, in bash.

$ ls .bash_profile
ls: cannot access '.bash_profile': No such file or directory
$ ls .bash_login
ls: cannot access '.bash_login': No such file or directory
$ ls .profile
ls: cannot access '.profile': No such file or directory

I have no these three files in my home dir.

> 
> A .profile which fails to dot in .bashrc will lead you to all kinds of
> subtle problems whenever you launch a login shell, which would normally
> be when you ssh in, or login on a text console.
> 
> A terminal emulator should normally run a NON-login shell, but some of
> them are sometimes configured to do the wrong thing because it works
> around stupid users.  So, if you're using a Desktop Environment that
> assumes you are a stupid user, it might be running your shell as a 
> login
> shell.
> 
> You can tell whether your shell is a login shell by looking at the
> name it's invoked with (via ps(1) or similar commands).  If the
> invocation name begins with a hyphen ("-"), it's a login shell.
> 
> 
> hobbit:~$ ssh localhost
> greg@localhost's password:
> Linux hobbit 6.1.0-28-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.119-1 
> (2024-11-22) x86_64
> [...]
> hobbit:~$ ps -fp $$
> UID          PID    PPID  C STIME TTY          TIME CMD
> greg     1001894 1001893  0 22:46 pts/29   00:00:00 -bash
> 
> 
> That's a login shell, because I ssh'ed in.  You can tell because it's
> invoked as "-bash" instead of "bash".  As a login shell, it will read
> my .profile, and my .profile contains:


$ ps -fp $$
UID          PID    PPID  C STIME TTY          TIME CMD
pyh        52921   52920  0 08:13 pts/0    00:00:00 -bash

This is my ps result, it seems I am using a login shell.

But as I said above, I have no .profile in my home dir.

> 
> 
> hobbit:~$ grep bashrc .profile
> . ./.bashrc
> 
> 
> so that my .bashrc file is *also* read.  Yours should have this too,
> or something fancier, maybe even
> 
>     test "$BASH" && source ~/.bashrc
> 
> or the default Debian /etc/skel/.profile way:
> 
>     # if running bash
>     if [ -n "$BASH_VERSION" ]; then
> 	# include .bashrc if it exists
> 	if [ -f "$HOME/.bashrc" ]; then
> 	    . "$HOME/.bashrc"
> 	fi
>     fi
> 
> which is ridiculously verbose.  I went with a more basic route.

So, since I am using a login shell, and I have .bashrc created. thus I 
have to create a .profile to include .bashrc? Am I right?

Thank you a lot.

Henrik

[toc] | [prev] | [next] | [standalone]

#276019

henrik@privatembox.com wrote:
> 
> So, since I am using a login shell, and I have .bashrc created. thus I 
> have to create a .profile to include .bashrc? Am I right?
> 
Yes, I think that's the right way round.

I use ssh a lot and have a 'standard' configuration for all the
systems I ssh into.

On all of them most of my basic environment settings are in .profile
and that calls .bashrc.

Make sure you **don't** have either ~/.bash_profile or ~/.bash_login
as these will be used instead of ~/.profile if they exist.

Note that (according to my understanding anyway) .bashrc should be
used for settings that are needed for interactive shells whereas
.profile is used for settings that are used by all programs not just
interactive ones.

-- 
Chris Green
·

[toc] | [prev] | [next] | [standalone]

#276020

> Sent: Thursday, December 26, 2024 at 5:56 AM
> From: "Chris Green" <cl@isbd.net>
> To: debian-user@lists.debian.org
> Subject: Re: bashrc question
>
> henrik@privatembox.com wrote:
> > 
> > So, since I am using a login shell, and I have .bashrc created. thus I 
> > have to create a .profile to include .bashrc? Am I right?
> > 
> Yes, I think that's the right way round.
> 
> I use ssh a lot and have a 'standard' configuration for all the
> systems I ssh into.
> 
> On all of them most of my basic environment settings are in .profile
> and that calls .bashrc.
> 
> Make sure you **don't** have either ~/.bash_profile or ~/.bash_login
> as these will be used instead of ~/.profile if they exist.
> 
> Note that (according to my understanding anyway) .bashrc should be
> used for settings that are needed for interactive shells whereas
> .profile is used for settings that are used by all programs not just
> interactive ones.
> 
> -- 
> Chris Green
> ·
> 
> 

[alarm@alarm ~]$ cat .bashrc
#
# ~/.bashrc
#

# If not running interactively, don't do anything
[[ $- != *i* ]] && return

alias ls='ls --color=auto'
alias grep='grep --color=auto'
PS1='[\u@\h \W]\$ '


[alarm@alarm ~]$ cat .bash_profile 
#
# ~/.bash_profile
#

[[ -f ~/.bashrc ]] && . ~/.bashrc

[toc] | [prev] | [next] | [standalone]

#276021

On Thu, Dec 26, 2024 at 10:56:31 +0000, Chris Green wrote:
> henrik@privatembox.com wrote:
> > 
> > So, since I am using a login shell, and I have .bashrc created. thus I 
> > have to create a .profile to include .bashrc? Am I right?
> > 
> Yes, I think that's the right way round.

Agreed.  Even if you just put in a single line to dot in ~/.bashrc
it should be sufficient.

> Make sure you **don't** have either ~/.bash_profile or ~/.bash_login
> as these will be used instead of ~/.profile if they exist.

Aye.

> Note that (according to my understanding anyway) .bashrc should be
> used for settings that are needed for interactive shells whereas
> .profile is used for settings that are used by all programs not just
> interactive ones.

For a user who only connects via ssh, a traditional model will work.
Configure .profile to set up your environment variables, umask, resource
limits, and so forth.  Anything that can be inherited goes in .profile.
Have .profile dot in .bashrc, and put all your non-inheritable shell
settings (set, shopt, alias, function) in .bashrc.

That's how it was designed to work originally, and that's the model
that ssh gives you.

If that's all you want to hear, you can stop there.  For a long ranting
explanation, read on.

In the original Unix workflow models, you would come to work, sit down
at your desk, turn on your terminal, and log in.  This would run a login
shell, which would read your ~/.profile, and set up your environment.
You could also do one-time jobs (show me today's calendar, big news
items, etc.) that you wouldn't want to do every time you launch another
shell.

What other shells?  Well, you might be editing a document, and decide
that you need to look something up, so you do a shell escape.  This
launches a NON-login shell, which is a child of your editor, which is
a child of your login shell.  You wouldn't want the new shell to show
you the daily calendar again, because you've already seen it.  Likewise,
you don't need the new shell to export your environment variables,
because you already have them.  They were inherited from the login shell.

Or, you might be using a terminal multiplexer like GNU screen, which
lets you open multiple virtual terminals on your single physical
terminal.  Each of those virtual terminals will inherit your environment
so they don't all need to re-export your variables, or show you the
big news items.  That would just be a waste of resources.

Or, you might be a little farther into the future, and using an X terminal,
which has a big fancy monitor and a mouse and can draw lots of windows.
In this kind of environment, you might open several terminal windows
simultaneously, and each one will run a non-login shell, because your
environment is inherited from your Window Manager application, which
launches the X terminals, which in turn launch the shells.

But things changed over time.  Unix started becoming widespread in
universities, where students would encounter it for the first time,
and have no idea how everything is set up, and how the different
processes work together.  A young student might edit their ~/.profile
equivalent (probably ~/.login back then because they were likely
using csh), and then wonder why it had no effect on their session.
The answer, of course, was that changes to .profile or .login only
take place when you log in, so you'd have to log out and back in to
get the changes.  Students didn't like that.  They wanted everything
to work immediately!  And what was that other file even for, .cshrc?
What was that?

So, for whatever reason, what started happening was university
environments would be set up so that all terminals launched login
shells by default.  Thus, students could modify their .login files,
never even TOUCH their .cshrc files, and every time they would launch
a new terminal, they would get their new settings.  It was as
inefficient as possible, but it was simple.

A whole generation of students therefore had their first exposure to
Unix in an environment where all shells were login shells.

Fast forward another generation, and we have the current crop of
abominations like GNOME, where nothing is inherited properly from any
discernable parent process, and nothing is user-configurable at all.
All terminals are children of a generic system daemon that you cannot
configure, and inherit nothing whatsoever.  In such an environment,
you're all but forced to configure all terminals to run login shells,
so that they can fully initialize their own environments ab initio.

So... what should you, the reader, do?  It all depends on your
environment.  How you login matters.  What kind of Desktop Environment
you run, if any, matters.  There are no longer any consistent rules
or policies.

[toc] | [prev] | [next] | [standalone]

#276034

On 26.12.2024 14:03, Greg Wooledge wrote:
> On Thu, Dec 26, 2024 at 10:56:31 +0000, Chris Green wrote:
>> henrik@privatembox.com wrote:
>> >
>> > So, since I am using a login shell, and I have .bashrc created. thus I
>> > have to create a .profile to include .bashrc? Am I right?
>> >
>> Yes, I think that's the right way round.
> 
> Agreed.  Even if you just put in a single line to dot in ~/.bashrc
> it should be sufficient.
> 
>> Make sure you **don't** have either ~/.bash_profile or ~/.bash_login
>> as these will be used instead of ~/.profile if they exist.
> 
> Aye.
> 
>> Note that (according to my understanding anyway) .bashrc should be
>> used for settings that are needed for interactive shells whereas
>> .profile is used for settings that are used by all programs not just
>> interactive ones.
> 
> For a user who only connects via ssh, a traditional model will work.
> Configure .profile to set up your environment variables, umask, 
> resource
> limits, and so forth.  Anything that can be inherited goes in .profile.
> Have .profile dot in .bashrc, and put all your non-inheritable shell
> settings (set, shopt, alias, function) in .bashrc.
> 
> That's how it was designed to work originally, and that's the model
> that ssh gives you.
> 
> If that's all you want to hear, you can stop there.  For a long ranting
> explanation, read on.
> 
> In the original Unix workflow models, you would come to work, sit down
> at your desk, turn on your terminal, and log in.  This would run a 
> login
> shell, which would read your ~/.profile, and set up your environment.
> You could also do one-time jobs (show me today's calendar, big news
> items, etc.) that you wouldn't want to do every time you launch another
> shell.
> 
> What other shells?  Well, you might be editing a document, and decide
> that you need to look something up, so you do a shell escape.  This
> launches a NON-login shell, which is a child of your editor, which is
> a child of your login shell.  You wouldn't want the new shell to show
> you the daily calendar again, because you've already seen it.  
> Likewise,
> you don't need the new shell to export your environment variables,
> because you already have them.  They were inherited from the login 
> shell.
> 
> Or, you might be using a terminal multiplexer like GNU screen, which
> lets you open multiple virtual terminals on your single physical
> terminal.  Each of those virtual terminals will inherit your 
> environment
> so they don't all need to re-export your variables, or show you the
> big news items.  That would just be a waste of resources.
> 
> Or, you might be a little farther into the future, and using an X 
> terminal,
> which has a big fancy monitor and a mouse and can draw lots of windows.
> In this kind of environment, you might open several terminal windows
> simultaneously, and each one will run a non-login shell, because your
> environment is inherited from your Window Manager application, which
> launches the X terminals, which in turn launch the shells.
> 
> But things changed over time.  Unix started becoming widespread in
> universities, where students would encounter it for the first time,
> and have no idea how everything is set up, and how the different
> processes work together.  A young student might edit their ~/.profile
> equivalent (probably ~/.login back then because they were likely
> using csh), and then wonder why it had no effect on their session.
> The answer, of course, was that changes to .profile or .login only
> take place when you log in, so you'd have to log out and back in to
> get the changes.  Students didn't like that.  They wanted everything
> to work immediately!  And what was that other file even for, .cshrc?
> What was that?
> 
> So, for whatever reason, what started happening was university
> environments would be set up so that all terminals launched login
> shells by default.  Thus, students could modify their .login files,
> never even TOUCH their .cshrc files, and every time they would launch
> a new terminal, they would get their new settings.  It was as
> inefficient as possible, but it was simple.
> 
> A whole generation of students therefore had their first exposure to
> Unix in an environment where all shells were login shells.
> 
> Fast forward another generation, and we have the current crop of
> abominations like GNOME, where nothing is inherited properly from any
> discernable parent process, and nothing is user-configurable at all.
> All terminals are children of a generic system daemon that you cannot
> configure, and inherit nothing whatsoever.  In such an environment,
> you're all but forced to configure all terminals to run login shells,
> so that they can fully initialize their own environments ab initio.
> 
> So... what should you, the reader, do?  It all depends on your
> environment.  How you login matters.  What kind of Desktop Environment
> you run, if any, matters.  There are no longer any consistent rules
> or policies.

Thanks for Greg and all others' help. that resolved my issue.

regards.

[toc] | [prev] | [next] | [standalone]

#276022

On 2024-12-26, henrik@privatembox.com <henrik@privatembox.com> wrote:
> Hello
>
> I have these settings in .bashrc of my home dir:
>
> $ cat .bashrc
> export TF_CPP_MIN_LOG_LEVEL=3
> export CUDA_VISIBLE_DEVICES=-1
>
> but every time after i login the system, the settings are not activated.
> I have to source it by hand to make it work.
>
> what's wrong with me?
>
> Thanks.
>
>
If your .bashrc settings are not applied automatically after login, here are
possible reasons and solutions:

.bashrc Might Not Be Sourced on Login Cause: .bashrc is typically sourced
for non-login shells, while .bash_profile or .profile is sourced for login
shells.

Solution: Add the following line to your .bash_profile (or .profile):

if [ -f ~/.bashrc ]; then
    source ~/.bashrc
fi
This ensures that .bashrc is sourced whenever you log in.

Login Shell Behavior Cause: If you're logging in through a graphical
environment (e.g., GNOME, KDE), it might not start a login shell.

Solution: Configure your terminal emulator to launch as a login shell. For
example:

In GNOME Terminal: Go to Preferences > Profiles > Command and check "Run
command as a login shell".  

Shell Type
Cause: If your default shell is not bash, your .bashrc will not be read.

Solution: Confirm your default shell with:

echo $SHELL
If the result is not /bin/bash, change your shell to bash:

chsh -s /bin/bash
Cause: Errors in .bashrc might prevent it from being sourced.

Solution: Check .bashrc for syntax errors:

bash -n ~/.bashrc
Fix any errors if found.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web