-1

I have an executable script which I want to run every time I log in or open a new interactive shell. I added the path to this executable in .profile and sourced it by adding this line to .profile

source $HOME/bin/wrapper

After rebooting, this script was not run.

Why is sourcing a script in .profile not executed by bash even after restarting fedora?

Edit: Made question clearer

bit
  • 1,076
  • 2
  • 17
  • 36
  • 2
    Probably because you have a `~/.bash_profile` which is being evaluated first. – jasonwryan Jul 17 '18 at 18:18
  • Are you using `/etc/.profile` or `~/.profile`? Is the source command executed on the command line or is it a line inside `.profile`? –  Jul 17 '18 at 18:25

2 Answers2

3

I did some investigating and came to understand there are two reasons sourcing scripts in .profile does not work:

  1. When you open a new terminal session, bash is run as an interactive non-login shell. Because .profile is run only for a non-interactive login shell, starting a terminal session does not run it.

  2. Although the script is sourced at login by .profile, unlike PATH environment variables which are exported to child processes at login when set in .profile, a source is a command and cannot be exported to child processes started from the first instance of bash initialised at login. In other words, source is interactive and needs to be in .bashrc which is the only start-up file that is run in an interactive non-login shell.

TL;DR .profile sources the script only once at login and it is not passed to the environment of the terminal session. Hence, I got the script to be sourced by putting it in .bashrc instead.

To answer the questions above, I don't have ~/.bash_profile and the source command was added to .profile

Bonus: For these reasons I assume an alias set in .profile also would not work as it is a command that needs to be executed each time a new environment is created in a terminal window.

bit
  • 1,076
  • 2
  • 17
  • 36
  • This doesn't make sense. In your question, you said the script wasnt run *after rebooting*, which would have sourced `~/.profile`. – jasonwryan Jul 17 '18 at 20:16
  • `~/profile` is sourced for interactive login shells, or for any shell started with `bash -l`. I don't know what you're saying in your second point. Using `source` on a script file will run the script in the current environment. This is regardless of what type of shell you're using (login/non-login). So the issue is that the terminal emulator is starting a non-login shell. This could have been clearer. Also, depending on what terminal you're using, it should be fairly easy to configure it to always start a login shell, if you so wanted. – Kusalananda Jul 17 '18 at 20:16
  • @jasonwryan let me try to clarify. It is an executable script, I assumed it wasn't run because I did not observe the expected effects. However considering how `.profile` works, it makes sense that it was run just once at login. – bit Jul 17 '18 at 20:26
  • @Kusalananda thanks for your thoughts. You may be right that ~/.profile is sourced for interactive login shells but my terminal is interactive non-login. Isn't that what I'm saying? - That the source added to `.profile` was run in the environment started at login but is not passed to the environment started by my terminal instance. The answer could probably be cleaned up a little. – bit Jul 17 '18 at 20:34
  • 2
    I think it *used* to be the case that display managers typically ran a user's GUI session via a login shell - but that's not so much the case nowadays. See for example [Gnome wayland session doesn't source ~/.profile](https://bugs.launchpad.net/ubuntu/+source/gnome-session/+bug/1631713) – steeldriver Jul 18 '18 at 00:26
  • @steeldriver : I think this is not really related to the display manager, but to the terminal program which you are using, and those usually allow you to specify the shell to be invoked, together with additional options for the shell - hence, you can configure it as a login- or non-login-shell, depending on your taste. – user1934428 Jul 18 '18 at 05:56
  • Thank you for the question AND answer, it helped me. Especially point 2. I am trying to source some functions collected in a script (rather than writing a separate $HOME/bin script for each) and was wondering why the functions didn't appear in my shell environments. Your question doesn't deserve negative votes, although it could be helped if you edit it to explain the effects you expected to observe. – trevor cook Jul 10 '19 at 13:34
1

From man bash (emphasis mine):

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.

You likely have a ~/.bash_profile, as jasonwryan said, so your ~/.profile is never read. This answer suggests sourcing ~/.profile in your ~/.bash_profile. You can do that, or you can source your executable script in ~/.bash_profile instead.

See also, Bash online manual.

Kevin Kruse
  • 378
  • 2
  • 13