1

There are a fair bit of similar questions, but I can't find spec for this particular case.

I'm writing a shell script to verify bash configuration. For exmaple, I add test_alias to ~/.bashrc, which is also sourced from ~/.bash_profile so the configuration can be loaded both for interactive and login shell. And I am aiming to test this within shell script for the users who previously had ~/.bashrc but had not sourced that in profile before. So I want to programatically test against profile configuration at ~/.bash_profile, not ~/.bashrc.

Here's an exmaple setup.

~/.bashrc

alias alias_test='echo "Test succeeded."'

~/.bash_profile

source ~/.bashrc

Then I go to shell and test them.

# Try testing in one line command for login shell
# I excect this to load profile before running command 
# provided in option.
# However it doesn't seem to have loaded it.
% bash -lc "test_alias"
> bash: line 1: alias_test: command not found

# Just to verify that the configuration itself is successful,
# if I try to do that interactively, it actually works.
% bash -l
[bash login shell] % test_alias
[bash login shell] > Test succeeded.

# This works too, but this isn't what I want to test 
# as I understand that this directly loads `~/.bashrc` 
# even without configuring profile.
% bash -ic "test_alias"
> Test succeeded.

This confuses me, because man bash does not seem to address this behavior.

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.

This looks to me as though -l (or --login) changes shell initialization behavior depending on the other factors such as if -c is set or not. However for some reasons I can't find the documentation or source that sites this.

What am I missing here?

By the way, the environment I'm testing on is macOS and bash is the one installed by homebrew. (GNU bash, version 5.2.37(1)-release (aarch64-apple-darwin24.2.0)

Improve this question
5
  • 2
    This question is similar to: Non-interactive shell expand alias. If you believe it’s different, please edit the question, make it clear how it’s different and/or how the answers on that question are not helpful for your problem. Commented May 26 at 5:40
  • @muru; While it explained why this is happening, it didn't clarify quite well on what needs to be done. If you don't mind, I may post one as answer to put together a few answers posted there to make it a complete q and a pair. Not sure if this thread should be removed altogehter but I guess I'll leave it up to someone else. Commented May 26 at 5:59
  • It's not entirely clear to me how you finally intend to use it. If you're actually writing an entire script that will individually test each alias by executing it in the script itself, then shopt -s expand_aliases in the script might be enough. But if the script is executing bash -c for each alias, then see the invocation in the answer below (though you might get away with bash -O expand_aliases -lc 'some-alias' depending on your environment) Commented May 26 at 9:06
  • You define an alias called alias_test but try to call test-alias. It is unclear what test-alias is. Commented May 26 at 10:35
  • @Kusalananda; Right, that was a typo, thanks for picking that up! @muru; -O option did the elegant trick for me! Thanks for the advice. Commented May 27 at 10:29

1 Answer 1

Reset to default
1

bash -c is to run inline scripts, where bash runs non-interactively like for regular scripts.

bash doesn't read user or system startup files when non-interactive (other than $BASH_ENV unless in POSIX/sh mode) unless its argv[0] starts with - or passed the -l/--login option in which case it interprets the login session initialisation files such as ~/.bash_profile (or ~/.profile when in POSIX mode).

But, bash also has that particularity that when non-interactive, it doesn't expand aliases unless it's in POSIX mode or the expand_aliases option (from its second set of options) is enabled.

So, here, for ~/.bash_profile to be read and for aliases to be expanded you need:

  • -l/--login or a argv[0] starting with - (but not being -sh or -/bin/sh...) or BASH_ENV=~/.bash_profile.
  • bash not being in POSIX mode, so $POSIXLY_CORRECT not set, no posix in $SHELLOPTS, not invoked as sh or with -o posix or --posix...
  • the expand_aliases option to be explicitly enabled like with shopt -s expand_aliases inside your ~/.bash_profile or ~/.bashrc if sourced from within ~/.bash_profile, or with -O expand_aliases passed to bash or with expand_aliases included in $BASHOPTS.
env -u POSIXLY_CORRECT -u SHELLOPTS bash -O expand_aliases -lc alias_test

Should do it (the env -u POSIXLY_CORRECT -u SHELLOPTS part probably not needed).

But if you only want ~/.bashrc to be interpreted, you could do:

BASH_ENV=~/.bashrc bash -O expand_aliases -c alias_test

(you may also need env -u POSIXLY_CORRECT -u SHELLOPTS as $BASH_ENV is not sourced when in POSIX mode which $POSIXLY_CORRECT and $SHELLOPTS could enable).

Though beware that that $BASH_ENV will be inherited by all commands run from that bash recursively. And if some of those are bash scripts, that will cause ~/.bashrc to be interpreted before the scripts themselves.

Improve this answer
1
  • This worked, just with -O option in addition. I missed the notion about shopt being required as mentioned in the comment too, and -O was another one that I didn't catch on top of that. I need to learn to read manpage better. Thanks for taking your time! Commented May 27 at 10:32

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.