Lockbox: call torizoncore-build from bash script

Technical Support
, ,
1

Hi,

I’m using the torizoncore-builder to download an already defined lockbox from the Torizon cloud.
When I call on the command line

source tcb-env-setup.sh -a remote
torizoncore-builder -h

this works fine.

Now I want to do this in a bash script:

#!/bin/bash
shopt -s expand_aliases

source tcb-env-setup.sh -a remote
torizoncore-builder -h

This also works well.

But when I change the script to the following

#!/bin/bash

bash -c "shopt -s expand_aliases; source tcb-env-setup.sh -a remote; torizoncore-builder -h"

I get the error that the command torizoncore-builder cannot be found.
Why is that?

Best regards,
Markus

2

Hi, I’m the Toradex AI Assistant.

I might make mistakes. Our support team will step in if needed. If I answered your question, please tick the “Solution” checkbox. For follow-up questions to me, please use @ToradexAI in your post.

Did you like my answer? :+1: :-1:

Hello Markus,

Great question! This is a common issue related to how shell aliases work in Bash, especially when dealing with subshells and scripts.

Why does it happen?

The TorizonCore Builder setup script sets up torizoncore-builder as a Bash alias (see docs)(more here). By default, Bash aliases are not inherited in non-interactive subshells and are available only in the shell session where the alias was defined and aliases are enabled.

In your last example:

bash -c "shopt -s expand_aliases; source tcb-env-setup.sh -a remote; torizoncore-builder -h"

you’re creating a new non-interactive shell. Even though you’re enabling alias expansion with shopt, the alias defined in tcb-env-setup.sh is valid only for that subshell. It will not persist or be exported to further child processes, and in non-interactive shells, some distributions or configurations may still not honor aliases fully.

Recommended solutions

  1. Use the same shell session:
    Either source the setup script and use the alias directly in your current shell (as in your working examples).

  2. Directly use the Docker run command:
    If you look in the tcb-env-setup.sh file, the torizoncore-builder alias typically points to a Docker run command. You could use this command directly in scripts for more predictability.

  3. Stick with sourcing in the script:
    As you’ve shown, the approach that works best in automation is to source the script in your Bash script, not in a subshell.

Summary

  • The alias only exists in the shell where it was defined and won’t be transferred to a bash -c context.
  • Sourcing in your script (source tcb-env-setup.sh -a remote) is the way to go for automation.

References:

Best regards,
Toradex AI Assistant.

3

ChatGPT o3 gave me a better answer :upside_down_face::

Why does the third case with bash -c "…" fail?
Alias expansion happens when the shell reads/parses the command, not when it executes it. In non-interactive shells (like bash -c), aliases are only expanded if expand_aliases is set — but only for aliases that already exist at parse time. If the alias is created by source …, then the following command in the same -c string has already been parsed, so no expansion occurs → “command not found”.

Solution:
re-parse after sourcing with eval:

bash -c 'shopt -s expand_aliases; source tcb-env-setup.sh -a remote; eval "torizoncore-builder -h"'

Best regards,
Markus