Best way to handle toolbox aliases

Ask Fedora
,
1

I’m running Fedora Kinoite and everything is either in a toolbox or a flatpack which was weird at first, but I’m starting to like it.

What is the recommended way to setup aliases so that they are available everywhere?
Currently I dump all of them in ~/.bashrc but that list is getting super long.

alias vim="flatpak run org.vim.Vim"
alias gradle="toolbox run -c dev /opt/gradle/gradle-8.1.1/bin/gradle"
alias java="toolbox run -c dev /usr/bin/java"
alias javac="toolbox run -c dev /usr/bin/javac"
alias htop="toolbox run -c dev /usr/bin/htop"
alias psql="podman exec -it postgres psql"
alias npm="toolbox run -c dev /usr/bin/npm"
...

and if I want to call some of these things from a .sh script, I’m forced to first call source ~/.bashrc otherwise the commands are not found.

#!/bin/bash

source ~/.bashrc

gradle doSomething
npm doSomethingElse

Is there a better way to do this?

2

Interestingly enough, changing the bash script to

#!/bin/bash -i

gradle doSomething
npm doSomethingElse

means I can get rid of the source

3

We talked lately about this:

I use the default paths proposed in .bashrc to store my .sh files (even if I not use the .sh extention).

# User specific environment
if ! [[ "$PATH" =~ "$HOME/.local/bin:$HOME/bin:" ]]
then
    PATH="$HOME/.local/bin:$HOME/bin:$PATH"
fi
export PATH

If you use ~/bin or ~/.local/bin you also not have to source them. Your system will find them with the path variable.

1 Like
4

One comment about using /etc/profile.d as the storage location for user defined scripts, aliases, etc.
It does work well, but will be wiped out when doing a new install as compared to an upgrade.

In contrast, the files placed under the users home directory are not wiped out during a new install as long as the user keeps their home data without reformatting.

1 Like
5

what about when using sudo?

currently when doing sudo vim .... the vim alias is not found but without sudo, the vim alias is working. Do I need a special bashrc for root too?

6
7

The sudo command uses the root user environment. If the regular user has aliases in his own environment they would not necessarily be seen within the root users environment.

For aliases to be seen by root they must be defined either by the root user, or be globally defined as would be done with putting them within the /etc/profile.d directory or withing the /etc/bashrc file.

1 Like
8

No, it doesn’t.

Defining the alias in the root user’s environment (e.g. in /root/.bashrc) would not work if another user types sudo <alias>. It would work if the user runs a login shell as root (sudo -i) and then types <alias>.

9

Of course not. The sudo <alias> command line is interpreted by bash as the invoking user before being processed, so the <alias> must be recognized before passing it to sudo. If not also recognized in the root user environment it fails.

The sudo -i command actually promotes the terminal to the root users environment and using the same alias there would again require that it be defined within the root users environment (either globally or as the root user specifically)

10

I guess the trick would be to use sudo in the alias statement. This way you can run it if you are in wheel group. If not you should get the regular error that you are not allowed to use this command.

p.s.

This would mean you have to create a sudo alias and a non sudo alias for dnf as an example.
For the sudo alias you have to use absolute paths so that you find the commands.

1 Like
11

Except in rare cases it is not recommended that one use the exact name of a system command for an alias. Doing so blocks access to the raw command without the added configs provided by the alias.
For example, the grep command in most recent fedora systems (workstation) has a global alias of

# alias grep
alias grep='grep --color=auto'

which means it always runs using the color option for all users.
And my regular user has these aliases defined by default

alias egrep='egrep --color=auto'
alias fgrep='fgrep --color=auto'
alias grep='grep --color=auto'
alias l.='ls -d .* --color=auto'
alias ll='ls -l --color=auto'
alias ls='ls --color=auto'
alias which='(alias; declare -f) | /usr/bin/which --tty-only --read-alias --read-functions --show-tilde --show-dot'
alias xzegrep='xzegrep --color=auto'
alias xzfgrep='xzfgrep --color=auto'
alias xzgrep='xzgrep --color=auto'
alias zegrep='zegrep --color=auto'
alias zfgrep='zfgrep --color=auto'
alias zgrep='zgrep --color=auto'

to that list, by default the root user adds

alias cp='cp -i'
alias mv='mv -i'
alias rm='rm -i'

which is a good thing.

12

For what it’s worth, I would just layer vim and htop if I wanted to use them on the host, and for the rest I would just enter the toolbox first before using them (I tend to have specific toolboxes for different organisations, and I just install the packages I need for that organisation’s projects). I’ve been using Silverblue this way for a few years now.

Nothing wrong with the way you’re doing it, but it’s a lot of plumbing!

13

A good alternative to aliases in this case are wrapper scripts. If you put them in a separate dir in your PATH you have them all in place and can use the from other scripts. Also, you can run them with sudo.
distrobox (a toolbox offspring) has an “export” command which does that (for binaries) and more (integration in app menus, integration of systemd units from container to host) if you need that.

1 Like
14

Here’s my unprivileged toolbx aliases

~/.bashrc.d/03-toolbx-aliases

# default fedora-toolbox aliases

# Make sure aliases don't run inside toolbx container
if ! [[ -f /run/.toolboxenv ]]; then
    toolbx_exports=(
        make
        m4
        seinfo
        sesearch
        sepolicy
        sepolgen
    )

    for cmd in "${toolbx_exports[@]}"; do
        alias "${cmd}"="toolbox run ${cmd} $*"
    done
    
    unset cmd toolbx_exports
fi

Check them out in the default shell:
alias |grep toolbox

alias m4='toolbox run m4 '
alias make='toolbox run make '
alias seinfo='toolbox run seinfo '
alias sepolgen='toolbox run sepolgen '
alias sepolicy='toolbox run sepolicy '
alias sesearch='toolbox run sesearch '

Sudo commands should go in it’s own configuration file for toolbx. Maybe like this:
alias dnf="toolbox run sudo dnf ${*}"

1 Like
15

the wrapper scripts idea works great in the cases where IntelliJ wants a physical file to point at

blah.sh:

#!/bin/sh -i

exec toolbox run -c dev /usr/bin/blah "$@"

Now I can point IntelliJ to these physical files

Thanks for the idea Michael!

16

I made me helper scripts to manage such wrappers. I use it for bash wrappers I store in ~/bin. If the .bashrc is original just creating a folder mkdir $HOME/bin is enough.

Use create WRAPPER-NAME as a template and opens nano with preconfigured text.

#!/bin/bash
# ilikelinux@fedoraproject.org
# create WRAPPER-NAME
read -p "Enter a subject for your file/script :" subject
read -p "Enter a source of your file/script :" source
tee ~/bin/$1 << EOF > /dev/null
#!/bin/bash
# example@example.com
##  $subject | `date '+%F; %T'` | $source
EOF
chmod +x ~/bin/$1
nano ~/bin/$1
exit

A index script, to list all the wrappers:

#!/bin/bash
## Making an index of a folder, containing filename and "## coment"
# ilikelinux@fedoraproject.org
cd ~/bin
/usr/bin/grep --color  -s --no-group-separator  '^## ' *

output:

create:##  $subject | `date '+%F; %T'` | $source
index:## Making an index of a folder, containing filename and "## coment"
test:##  test | 2023-05-12; 01:46:51 | https://discussion.fedoraproject.org/t/best-way-to-handle-toolbox-aliases/82393/16

If someone find this snippets useful and tunes them, please give feedback.

2 Likes