Is there some reason you just don’t export those env vars in $HOME/.bashrc or $HOME/.bash_profile?

export SOME_ENV_VAR=value

If it’s every time you run the command, seems like it should be set globally.

You could source an aliases.sh file on your .bashrc where you define your aliases, so that they don’t fill up your bashrc.

For example, in your bashrc:

source ~/.aliases.sh

This way you could also create a file with aliases per program.

function command_one() {
    # activate the environment
    source "$XDG_DATA_HOME/venvs/alpha.sh"
    # run the thing
    actual_command_one
}

function command_two() {
    # activate the environment
    source "$XDG_DATA_HOME/venvs/alpha.sh"
    source "$XDG_DATA_HOME/venvs/bravo.sh"
    # run the other thing
    actual_command_two
}

You can add a new executable in your ~/.local/bin directory like command_custom that would start SOME_ENV_VAR=value command. Like if you use bash:

#!/usr/bin/bash

SOME_ENV_VAR=value command

Do not forget to chmod +x the file to make it executable.

This way you will have additional command for your user only (no sudo require to create/update those), for system-wise command put it in /usr/local/bin.

You could write a shell script:

#!/usr/bin/env sh

export SOME_ENV_VAR=value

command

Then place it on your path, for example /usr/local/bin/command_with_env.

I avoided overriding the command itself and naming the script the same, because then I think it would try to invoke itself.

Put your aliases in .bash_aliases

Make sure your .bashrc sources .bash_aliases like this:

if [ -f ~/.bash_aliases ]; then . ~/.bash_aliases fi

Structure your .bash_ files. Have a .bash_aliases and a .bash_functions, then just source them from your .bashrc. If you’re like me, they may get a little busy, but it’s not really that big of a deal to prune the files every couple years. I find things that I added for jobs, used a lot on the job, then not at all afterwards. It helps to comment the hell out of your files, but it’s not super necessary. You could break up your aliases into different files by program and source them, but that seems like more work for not much payoff.

You could alias the your programs’ commands to invoke the environment variables.

Or, use an alias to source an environment file before launching the binary?

If you were using Zsh, one way you could do this is by autoloading function files from a folder in your fpath.

Let’s say you’re using ~/.local/share/zsh/site-functions for your custom functions. To ensure that folder is an early part of your fpath, put something like this within your .zshrc:

typeset -U fpath=(~/.local/share/zsh/site-functions $fpath)

Then let’s say you want to override the uptime command. Add a file ~/.local/share/zsh/site-functions/uptime with content like:

NO_COLOR=1 =uptime

 `=' expansion
     If  a word begins with an unquoted `=' and the EQUALS option is set, the remainder of the word is taken as the name of a command.  If a command ex‐
     ists by that name, the word is replaced by the full pathname of the command.

The last thing you need to do is mark it for autoloading, in your .zshrc:

autoload -Uz uptime

Instead of listing those functions manually as arguments, you could instead use a glob pattern to collect all those names, excluding any which begin with _ (completion functions):

autoload -Uz ~/.local/share/zsh/site-functions/[^_]*(:t)

deleted by creator