My question is whether it is good practice to include a unique wrapper phrase for custom commands and aliases.

For example, lets say I use the following command frequently:

apt update && apt upgrade -y && flatpak update

I want to save time by shortening this command. I want to alias it to the following command:

update

And lets say I also make up a command that calls a bash script to scrub all of of my zfs and btrfs pools:

scrub

Lets say I add 100 other aliases. Maybe I am overthinking it, but I feel there should be some easy way to distinguish these from native Unix commands. I feel there should be some abstraction layer.

My question is whether converting these commands into arguments behind a wrapper command is worth it.

For example, lets say my initials are “RK”. The above commands would become:

rk update rk scrub

Then I could even create the following to list all of my subcommands and their uses:

rk --help

I would have no custom commands that exist outside of rk, so I add to total of one executable to my system.

I feel like this is the “cleaner” approach, but what do you think? Is this an antipattern? Is is just extra work?

  • crime [she/her, any]@hexbear.net
    link
    fedilink
    English
    arrow-up
    2
    ·
    4 months ago

    Others have rightly pointed out that these abstractions can sometimes negatively impact muscle memory, but IMHO this only really applies if you work as devops or sysadmin

    I feel both seen and called out lol

      • crime [she/her, any]@hexbear.net
        link
        fedilink
        English
        arrow-up
        2
        ·
        3 months ago

        No offense taken, I just wasn’t expecting to get read like that lmao — I guess having to operate Other People’s Servers really causes a certain kind of (recognizable) cynicism