In my ~/.bashrc file reside two definitions:
commandA, which is an alias to a longer pathcommandB, which is an alias to a Bash scriptI want to process the same file with these two commands, so I wrote the following Bash script:
#!/bin/bash
for file in "$@"
do
commandA $file
commandB $file
done
Even after logging out of my session and logging back in, Bash prompts me with command not found errors for both commands when I run this script.
What am I doing wrong?
If you look into the bash manpage you find:
Aliases are not expanded when the shell is not interactive, unless the expand_aliases shell option is set using shopt (see the description of shopt under SHELL BUILTIN COMMANDS below).
So put a
shopt -s expand_aliases
in your script.
Make sure to source your aliases file after setting this in your script.
shopt -s expand_aliases
source ~/.bash_aliases
shopt -s expand_aliases source ~/.bash_aliases works perfectly for me. Often there is a form of interactive shell detection in .bashrc like this: # If not running interactively, don't do anything [ -z "$PS1" ] && return @Zaid, Maybe you want to check for that in the file you sourced.
shopt -s expand_aliases doesn't have to go before the alias definition but before the alias use. Adding to @FrankSchubert: Interactive shell detection may also be done using $- which contains the options for the shell, specifically i if the shell is interactive.
~/.bash_aliases might depend on other stuff previously loaded on an interactive shell... The closest thing I found is changing your hashbang to #!/bin/bash -li Still not perfect. Ideally you should use functions and not aliases.
bash -c, for example bash -c "shopt -s expand_aliases; source my-script.sh; some-alias. Still get some-alias: command not found
First of all, as ddeimeke said, aliases by default are not expanded in non-interactive shells.
Second, .bashrc is not read by non-interactive shells unless you set the BASH_ENV environment variable.
But most importantly: don't do that! Please? One day you will move that script somewhere where the necessary aliases are not set and it will break again.
Instead set and use variables as shortcuts in your script:
#!/bin/bash
CMDA=/path/to/gizmo
CMDB=/path/to/huzzah.sh
for file in "$@"
do
$CMDA "$file"
$CMDB "$file"
done
alias use cases. E.g. alias mv="mv -v --backup=numbered".
$CMDA / $CMDB… Apart from uppercase variables being reserved for bash itself in bash, and it indeed working, that lack of quotes makes me really uneasy… Thanks anyway.
gizmo is not on the path or there is a command with the same name but a higher priority. else you could simple set CMDA to plain gizmo in the first place.
Aliases can't be exported so they're not available in shell scripts in which they aren't defined. In other words, if you define them in ~/.bashrc they're not available to your_script.sh (unless you source ~/.bashrc in the script, which I wouldn't recommend but there are ways to do this properly).
However, functions can be exported and would be available to shell scripts that are run from an environment in which they are defined. This can be done by placing this in your bashrc:
foo()
{
echo "Hello World!"
}
export -f foo
As the Bash manual says, "For almost every purpose, shell functions are preferred over aliases."
alias commandA=... with commandA() { ... } then export commandA and you get identical behavior to the alias. So this is pretty much an identical alternative to aliases as far as I know that works great in bash scripts
alias b=bash makes it easy to do b -c "echo test | grep test" which would be difficult to do in functions.
b () { bash "$@"; } then b -c "echo test | grep test"
[cmd line] > bash -i [your script's file path]
The i is for interactive and sources your bash profile for you.
You can also use . before your script. Run it as:
. /path/to/your/script.sh
You can check for this condition on your bash script as follows:
if [[ $- == *i* ]]
then
echo "running on interactive mode. aliases will work!"
fi
set -e, and running it this way causes the set -e to carry over into other bash sessions once the script exists, causing my terminals to exit when any non-zero code is encountered, even just trying to use tab completion. It was pretty frustrating to track down, not complaining -- just putting it here to help.
source ~/.bashrc.