Has when .profile is used been changed?

General system Newbie
1

My ~/.profile contains:

# . /home/me/bin/udpath.sh
source /home/me/bin/udpath.sh

(originally used the “./” format and “source” was commented out)

And /home/me/bin/udpath.sh contains:

export PATH=$PATH:/home/me/bin:/home/me/bin/perl
echo $PATH  # Updated path

Until yesterday {13th of February) this has always worked (since i started using EOS), i.e. it has set my PATH variable for every terminal i started.
However, yesterday it just stopped working - PATH variable remained set to default.

I had no time to look yesterday …
Today i noticed that the ~/.profile file was not set to run as a program plus it and ~/.bashrc (and more) did not start with shabang - which i’d never noticed before so maybe …?

Has something changed in EOS to stop a terminal adding the .profile when it starts?

Or … ??

Any thoughts would be appreciated … even telling me where i should really be sticking my path change.

2024-02-14T00:00:00Z

2

What shell are you using?

3

Sorry, Bash
I’ve not done any changes to the basic EOS xfce system

4

If memory serves, .profile isn’t run by bash when you open a terminal. It is executed when you login. I suspect it is/was being loaded by being called from somewhere else or because the terminal inherits those values from the environment.

I am not sure what has changed. I suppose it could be a lot of things.

Either way, if you want something in your terminal primarily, you should put them in ~/.bashrc. By default, ~/.bash_profile also loads ~/.bashrc so changes there should always be available in interactive shells.

5 
bash --version
GNU bash, version 5.2.26(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
printf "\033]0;%s@%s:%s\007" "${USER}" "${HOSTNAME%%.*}" "${PWD/#$HOME/\~}"
6

This is what is stated in Bash Reference Manual:

When Bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it first reads and executes commands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable.

It says there that bash will read and execute commands from the first one that exists and is readable.

Could it be that ~/.bash_profile and ~/.bash_login didn’t exist before? That’s why the commands in .profile were executed—because ~/.profile was the only file that existed.

If either ~/.bash_profile or ~/.bash_login exists, ~/.profile will be ignored.

7

A new terminal shouldn’t be a “login shell”. The login is probably happening earlier in this case.

8

I’m a bit confused. If the OP’s custom paths were added to PATH during login, wouldn’t it also be accessible from a terminal? Do you mind clarifying?

When we are trying to login from a tty, does that count as an interactive login shell?

9

Thanks Dalto

added below to ~/.bashrc

# set MY paths
if [ -f . /home/me/bin/udpath.sh ]; then
    . /home/me/bin/udpath.sh
fi

… still not working.
Unless it needs a reboot - tomorrow is another day :))

10

Yes. But that doesn’t mean they were added by bash.

Yes. Also, ssh login.

But not a new terminal I don’t think.

1 Like
11

Are you seeing the echo when you open a new terminal?

12

Probably because there is a typo in the conditional. There shouldn’t be a . after -f

1 Like
13

Maybe Anthony but …

~/.bash_profile does exist now
and it includes:

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

and my ~/.bashrc now includes code shown above: #8

14

No Dalto, no echo, however, …

What i do see is the stuff shown below as the first line in the terminal followed by my usual prompt line:

bash: [: .: binary operator expected

Also, MY paths have not been added
yet my aliases (set in similar link at end of .bashrc)
have been set.

15

Like I mentioned above, you have a typo in the conditional.

16

Bugger!
That’s what you get why pasting cos i’m a lazy old git and only got one eye atm.
Thanks Anthony, sod Jupiter, that was a great spot :))

All working fine.
It even displays the required path with my bits showing

Thanks to everyone.
You’re very kind as well as brilliant.

1 Like
17

Since you mention login, I recall there has been change in LightDM. Is this relevant here:

tldr: its not loading .profile unless the shell is sh. Renaming .profile to .xprofile should fix it?

Edit:

Seems like OP had their issue solved.

Edit 2: A user on the subreddit had the same issue too as OP.

1 Like
18

If the OP is indeed using LightDM, then yeah. I think this is relevant. This in fact explains the behavior described by the OP, at least in my view. Xsessions used to source .profile regardless of the shell in use. But now, it will only source ~/.profile if the shell in use is sh, ksh, etc.

Since the OP is using bash, only this code will be run:

*/bash)
    [ -z "$BASH" ] && exec $SHELL --login $0 "$@"
    shopt -q login_shell || exec $SHELL --login $0 "$@"
    set +o posix
    ;;

In other words, it will fallback to the default bash behavior as mentioned here:

Since .bash_profile exists in the OP’s home directory, only .bash_profile would be sourced whereas .profile would be ignored, which didn’t use to be the case because before that change, the case statement didn’t exist.

# The code before the change
# Load profile
for file in "/etc/profile" "$HOME/.profile" "/etc/xprofile" "$HOME/.xprofile"; do
    if [ -f "$file" ]; then
        echo "Loading profile from $file";
        . "$file"
    fi
done
1 Like