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?

26 points
*

Personally I had to come to terms with the idea that anything other than just running the raw commands will get me into trouble. I work on a lot of servers, and so I need to be able to rely on my shell knowledge even when my bashrc isn’t handy. So for me it became more about just remembering what software does what thing broadly, and then checking man for the finer details.

But for a single personal machine, script it however you want. Just be aware that you’ll start to build muscle memory for aliases and custom functions that won’t follow you to new machines.

permalink
report
reply
13 points

an easier approach to start with would just be to namespace them all with your initials when you set them as aliases, like rk-update, rk-scrub — then you could tab-complete them instead of doing rk --help. way less to maintain (unless you’re adding aliases from a bunch of different sources, in which case you may have bigger problems)

permalink
report
reply
8 points
*

I have about 25 or so shell scripts I use somewhat regularly and well over 300 aliases. I actually specifically don’t wrap package manager related scripts for no reason in particular, but many often do.

My rule for an alias is if the amount of custom flags gets lengthy, and I use it often, yeah it gets an alias. Here’s an example of using yt-dlp:

alias ytdl='yt-dlp --sponsorblock-remove all --write-auto-sub -f "bestvideo\*+bestaudio[ext=m4a]/best" -f mp4'

For shell scripts, my rule goes that it should probably have multiple features related around a single idea, that way you can use getopts to create custom flags. For example, I have a script that wraps very basic, but commonly used, git commands, chaining the classic add, commit -m, and push behind a series of read prompts, it has -h flags for help -l for a minimal log output, -i to initialize a new repository (even using github api token to remotely create the repo if you want to use github), and -r to revert back changes to a specified commit.

Generally speaking aliases will get you what you need most of the time in a pinch, but shell scripting is more powerful, versatile, but potentially more time consuming.

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, where you are often responsible for running many different Linux servers, but usually this isn’t an issue if you have access to the internet and can see your saved aliases and/or scripts (but yeah, instant recall of native commands trumps notes every time).

Additionally, another mentioned using git to keep track of your aliases, which I totally agree with. Whatever you do, back up your aliases and shell scripts, ideally with a git repo of some kind. This not only allows you to take your new scripts/aliases with you wherever you go, but also reference them later in case it’s not possible to use them on not your machine.

Hope this helps. Bash can be crazy powerful if you take the time to learn it, and aliases are a great entry point to recognizing that potential. Here’s one of my favorites that combines mkdir with cd:

alias mkcd='{ IFS= read -r d && mkdir "$d" && cd "$d"; } <<<' 

Good luck, and have fun.

permalink
report
reply
2 points

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

permalink
report
parent
reply
1 point

Lol. Emphasis on the H in IMHO. I meant no offense, it’s a valid point.

permalink
report
parent
reply
2 points

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

permalink
report
parent
reply
5 points

Good idea I’d say.

permalink
report
reply
5 points

What you described is a common practice to make oneself life easier.

If you want to write something like rk you would need to create a bash script and place it in your PATH so you can access it from there. It is fairly easy to do so, and you can back it up in GIT so that you have the latest version of the command line utility there. Even for the alias, I would say back it up in GIT, because you might lose them.

permalink
report
reply

Linux

!linux@lemmy.ml

Create post

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

  • Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
  • No misinformation
  • No NSFW content
  • No hate speech, bigotry, etc

Related Communities

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

Community stats

  • 7.4K

    Monthly active users

  • 6.6K

    Posts

  • 179K

    Comments