Sourcing ~/.bash_profile / ~/.profile before ~/.bashrc makes sense, and from testing this I don't notice any issues.

I don't really have a good grasp of what order, and how, the various profile and rc files are suppose to be sourced, so I would like to get a second approval opinion here (or time for me to read bash's documentation)

I was gonna post the comment yesterday but got busy with some other stuff to complete it.

If we are going to be changing the behaviour of startup files, best think on this from a future perspective as well.

The behaviour would depend on distros of course, but the debian/ubuntu defaults are below.

The following are provided by the base-files package.

• /etc/profile
• ~/.profile
• ~/.bashrc

The following are provided by the modified bash package provided by debian itself.

• /etc/profile (Ubuntu 20.04 is using the base-files one instead, probably debian does too)
• /etc/bash.bashrc

The /etc/bash.bashrc is not provided by GNU bash and is disabled by default and debian bash has a patch to enable it internally by defining SYS_BASHRC.

You can check the invocation order in debian manpage for debian specific order and in GNU manpage. Its handled by bash/shell.c. The SYS_PROFILE = /etc/profile, DEFAULT_BASHRC/bashrc_file = ~/.bashrc and SYS_BASHRC = /etc/bash.bashrc.

The debian logic is the following.

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. The --noprofile option may be used when the shell is started to inhibit this behavior.

When an interactive login shell exits, or a non-interactive login shell executes the exit builtin command, bash reads and executes commands from the file ~/.bash_logout, if it exists.

When an interactive shell that is not a login shell is started, bash reads and executes commands from /etc/bash.bashrc and ~/.bashrc, if these files exist. This may be inhibited by using the --norc option. The --rcfile file option will force bash to read and execute commands from file instead of /etc/bash.bashrc and ~/.bashrc.

When bash is started non-interactively, to run a shell script, for example, it looks for the variable BASH_ENV in the environment, expands its value if it appears there, and uses the expanded value as the name of a file to read and execute. Bash behaves as if the following command were executed:

Only the first file in B is started.

1. Currently, termux is using GNU bash and not the one provided by debian but does apply some debian patches, like for /etc/bash.bashrc. Would need to look into the other patches as well to see what if any missing differences exist.

2. Termux is running /etc/profile.d/*.sh before sourcing /etc/bash.bashrc, which is the wrong order, so at least that should be fixed.

3. I agree with the removal of sourcing of ~/.bashrc done in /etc/profile, that is not the place for it and bash will automatically call it for interactive non-login shells. Sourcing it in ~/.profile for interactive login shells should be setup manually by the user or as part of bootstrap/termux-tools setup as per debian config. By default only ~/.profile and ~/.bashrc exist in debian/ubuntu. The ~/.bash_profile does not exist but a sample file is provided by adduser package. So we can technically install some default files in bootstrap/termux-tools setup.

4. There is no [ "${PS1-}" ] check in termux /etc/profile as there is in debian /etc/profile. The ${PS1-} expansion is needed due to this. The bash default PS1/PPROMPT is \s-\v\$ and should be set to $PS1 variable during shell initialization.

5. The termux /etc/bash.bashrc does not automatically return if PS1 is not set. It's not supposed to run for non-interactive shells.

6. There should be an explicit check for if ! [ -n "${SUDO_USER}" -a -n "${SUDO_PS1}" ] like done in debian /etc/bash.bashrc before termux /etc/bash.bashrc sets the PS1. Otherwise, it causes problems described at https://github.com/agnostic-apollo/sudo#ps1, where PS1 is overridden. If this gets fixed, then both tudo/sudo can use SUDO_PS1 to prevent overwrite instead of users having to modify default startup files.

7. This is more of philosophical point. Should every new terminal started by termux be an interactive login shell instead of just being an interactive shell? Although, not sure how inheritance would be done of env variables, etc from login shells into non-login shells, since termux app itself is not a login shell. So likely not possible for termux. Seems like OSX runs a login shell for every terminal too https://unix.stackexchange.com/questions/119627/why-are-interactive-shells-on-osx-login-shells-by-default.

I don't think these changes should affect any "systemd" implementation that is done in termux app in future. Systemd does not run any startup files and has its own environment files. https://unix.stackexchange.com/a/455283

What I'm proposing is to just provide bootstrap rc files (like /etc/skel on Linux distributions) that will be placed into $HOME on first login or if not exist, in addition to fix order. However rc files, whether this is ~/.profile or ~/.bash_profile should load ~/.bashrc on interactive login shell if exist and without additional inputs from user.

Should every new terminal started by termux be an interactive login shell instead of just being an interactive shell?

Yes, it should be login shell for every opened terminal as we don't have other way to "log in". On Linux distribution login shell is started when user logged in through TTY console or SSH and terminal emulators start the non-login shell by default.

whether this is ~/.profile or ~/.bash_profile should load ~/.bashrc on interactive login shell

Agreed, this should be ~/.profile as per debian, with check for $BASH.

https://sources.debian.org/src/base-files/11.1+deb11u1/share/dot.profile/#L5

other way to "log in".

Yeah, already get all that... I was just talking from the perspective of login shell stuff being run every time. Do plan on exporting an ENV variable from termux-app for session count till now if login shell is started (not RUN_COMMAND). Users can at least use that.

This issue/PR has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

This PR seems to be 2.5 years old. Should we keep it open or we can close it?

Will need to be eventually worked on, so fine to keep open.

Loading the bashrc from the system profile is problematic because it invokes the bashrc before the environment from the user profile is loaded. Conditionally sourcing the bashrc should happen from the user profile, which can be deployed to user homes via the /etc/skel mechanism.