Calling a Bash script from within another bash script on Debian Buster VM

Question

I have a script, someutil.sh which I would like to call in another script main.sh.

Both scripts are:

• In ~/bin and are executable (chmod +x someutil.sh).
• Headed with #!/bin/bash
• Functional from the command-line

$PATH includes ~/bin by default and ~/.bashrc includes the aliases:

alias someutil="someutil.sh"
alias main="main.sh"

I have attempted to run someutil inside the script in the following ways

• someutil args (identical to usage on interactive command line)
• ./someutil args
• ~/bin/someutil.sh args

Main.sh executes but gives a "command not found" error for the "someutil" if I try to use the alias.

someutil also creates a file to use temporarily (in the home directory) which it then tries to append some data to (using >>, but this throws a "Permission denied error"). However, the parts where I use "sed -i ..." with the file as an input file work fine.

I have also tried following the advice from these answers:

• https://stackoverflow.com/a/8352939/1669825
• Having trouble calling a bash script from another bash script

The only thing that works is to call the function using ~/bin/someutil.sh but I would really like to use the aliases (for readability) and add the commands to the path to avoid always giving a full path. I also don't understand why the script that creates a file cannot later edit it...

So, I am clearly missing something with either the path variable (different path variables for different users or environments), or somehow not understanding which permissions the scripts run under when executed.

I am using Debian Buster on a virtual machine on a Chromebook ("Linux development environment (Beta)").

Help would be appreciated!

Answer 1

Courtesy of @cyrus and this answer, the solution was to add the following to the beginning of my main.sh script:

shopt -s expand_aliases
source ~/.bash_aliases

Then, I could use my custom scripts the same way as in the interactive shell.

The issue regarding permissions for the temporary file was a simple, unrelated syntax error which resulted in the script attempting to execute the file instead of what was intended (see this answer)