this post was submitted on 06 Jul 2023
2 points (100.0% liked)

Linux

48031 readers
1156 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS
 

hello friends,

I am looking for a way to do what I described in the title. When running command command, I dont want to have to type SOME_ENV_VAR=value command every time, especially if there are multiple.

I am sure youre immediately thinking aliases. My issue with aliases is that if I do this for several programs, my .bashrc will get large and messy quickly. I would prefer a way to separate those by program or application, rather than put them all in one file.

Is there a clean way to do this?

top 16 comments
sorted by: hot top controversial new old
[–] nicoag328@lemmy.ml 4 points 1 year ago (2 children)

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.

[–] treadful@lemmy.zip 1 points 1 year ago (1 children)

FYI: $HOME/.bash_aliases is standard and most distros' .bashrc will source that file by default.

[–] oranki@sopuli.xyz 0 points 1 year ago (1 children)

Most Debian based distros, actually.

[–] treadful@lemmy.zip 1 points 1 year ago

And at least arch. Probably others.

[–] cyclohexane@lemmy.ml 0 points 1 year ago (1 children)

That's a good idea, but it only makes the problem a little better. I still wouldn't want one large aliases.sh file with environment variables for every application I customized. Would rather have them separate somehow without gobbling up a file

[–] nicoag328@lemmy.ml 1 points 1 year ago

You can source other files inside aliases.sh or as @treadful noted .bash_aliases

.bash_aliases:

source .aliases/program_x.sh source .aliases/program_y.sh

This way you can have a file with aliases for each application or group of applications.

But it would be helpful if you provided more information on what you really want to do. Read https://xyproblem.info/

[–] dlarge6510@lemm.ee 3 points 1 year ago* (last edited 1 year ago)

Put your aliases in .bash_aliases

Make sure your .bashrc sources .bash_aliases like this:

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

[–] Kajika@lemmy.ml 2 points 1 year ago

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.

[–] treadful@lemmy.zip 2 points 1 year ago (1 children)

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.

[–] cyclohexane@lemmy.ml 1 points 1 year ago (1 children)

Because it's not as maintainable as separating them by application or some other separation. Would not want to fill up my bashrc with single-application specific code.

[–] treadful@lemmy.zip 3 points 1 year ago

You could break it out into other files if you really got that much going on. But if you really have hundreds or more env vars, maybe you should re-think using env vars at all.

Hard to give a rec without more detail, so I don't really get it.

[–] Andy@programming.dev 1 points 1 year ago* (last edited 1 year ago)

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

Explanation for the second =:

 `=' 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)
[–] manned_meatball@lemmy.ml 1 points 1 year ago
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
}
[–] oscar@programming.dev 0 points 1 year ago (1 children)

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.

[–] deong@lemmy.world 0 points 1 year ago (1 children)

Just replace command in your script with /usr/bin/command or whatever. It’s generally good practice to full path anything run from a script anyway just to remove any unintended environment dependencies.

[–] oscar@programming.dev 1 points 1 year ago

Good point. But then if both the script and the command have the same filename, it will be important to make sure the script has a higher precedence in the PATH. Adding it to the end of .bashrc should be enough I think.

load more comments
view more: next ›