Creating a few aliases in Solus

Discussion
1

A while back I was reading an item about Bash Built-ins from the Linux Handbook newsletter and I saw that alias is a built-in command. I had forgotten all about it and how useful it can be. The bash built-ins do not have man pages. If you want information on one of them you must use the help command with the commands name e.g.: “help alias” (no quotes). Then, at the end of that item, I saw another item specifically about the alias command and using it in the ~/.bashrc file to simplify repetitive/complex operations that require the execution of two or more commands sequentially (one after the other). The item used updating a Debian/Ubuntu based distribution as an example. The syntax for creating an alias in ~/.basrc is:

alias alias_Name 'command(s)'
    # Note: if the command string contains any spaces, it MUST be enclosed in single quotes.
    # The alias name must be a single word – no spaces.

I liked that idea so I decided to create a few aliases of my own. I started with an alias to update Solus. I started by finding out how to update Solus from the terminal. Since the GUI Software Manager handles updates very well, I hadn’t taken any time to learn that yet. The command I need to update Solus from the command line is ‘sudo eopkg upgrade’. The command(s) for your distribution will be different if you are not a Solus user. With that command I was ready to create my first alias in ~/.bashrc. I opened a terminal emulator window and entered “nano ~/.bashrc” to open the file for editing. I was surprised by the fact that the file had only one line (I don’t remember what it was any more), so I added a blank line and created my first alias. I entered a descriptive comment and my alias command to update Solus:

# Update the system
alias update 'sudo eopkg upgrade'

Now (after saving my changes then closing and re-opening the terminal emulator), when I enter ‘update’ at the command prompt, I’m asked for my administrative password, then the command executes.

I use OneDrive in Windows, and I want to be able to access my files stored there from my GNU/Linux distribution. Several years ago, I found a onedrive client on GitHub (GitHub - abraunegg/onedrive: #1 Free OneDrive Client for Linux). At first I had to build each release from source, removing the old version before building/installing the new one. Today, many distributions (including Solus) have it in their repositories, so updates occur with system updates (no fuss - no muss). I can run the onedrive client as a system service, and I did for a while so the client synchronized with the server every five minutes, but I didn’t like waiting five minutes after adding a file to my local directory to ensure it uploaded before switching back to Windows during those times when I was finished doing whatever I switched to Linux to do, so now I synchronize OneDrive almost manually. I have KDE configured to synchronize with the server at system start. I do the synchronization manually before I shut down or reboot to Windows. I decided to create an alias to synchronize OneDrive named simply “sync” (no quotes) and the entry for that is:

# Synchronize OneDrive
alias sync ‘onedrive –synchronize’

The only complaints I have about Solus so far are that it does not show the boot-up menu in a dual-boot scenario or respect my configuration choices regarding boot-manager configuration by default. Solus uses clr-boot-manager, which in turn uses systemd-boot. When the system starts, the EFI partition is mounted on the /boot directory, then dismounted after the system starts (to protect it from inadvertent corruption - a nice security/stability feature), so when I tried to look at the EFI partition in Solus for the first time I was surprised to see nothing in the /boot directory. That’s when I learned how Solus handles the system boot up process with a few minutes of reading the Solus online help system – the boot-manager section, and by viewing the boot manager’s help information in the terminal where I learned about the “mount-boot” and “set-timeout” arguments that mounts the EFI partition on the /boot directory and sets the boot-manager timeout to make the boot-up menu visible for the specified number of seconds (I chose 5) respectively. The reason I say Solus does not respect my configuration choices is that after a system update, the boot manager returns to its initial behavior of selecting Solus at boot time regardless which OS I’m in when I restart the computer. Interestingly, it does not revert the timeout setting, only the default (choice) setting. The result is that following a system update I have to restore the configuration I want by editing the /boot/loader/loader.conf file manually. My next project will be to find a way to restore my chosen configuration so I can use that process in my update alias (above), but for now, I have created an alias to fix my boot configuration in nano. The entry for this alias is:

# Mount the EFI partition and edit the loader.conf file
alias fixboot='sudo clr-boot-manager mount-boot && sudo nano /boot/loader/loader.conf'

# Note: I used ‘&&’ to separate commands (it must be enclosed in space characters a shown above).
# && tells bash to run the second command only if the first command succeeds.

My fixboot alias mounts the EFI partition on /boot then opens the loader.conf file in nano so I can restore my desired configuration.

That’s about it. With these three examples you should be able to learn what you need to make fairly complex things happen with a single word.

UPDATE
While writing this post, it occurred to me that I could copy my loader.conf file as a backup:

sudo cp /boot/loader/loader.conf /boot/loader/loader.conf.bak

After creating my backup file containing my desired configuration I change my update alias as follows:

# Update the system
alias update='sudo eopkg upgrade && sudo clr-boot-manager mount-boot && sudo cp /boot/loader/loader.conf.bak /boot/loader/loader.conf'

To test that this works I added a comment at the bottom of the backup file “# configuration restored” that’s not in /boot/loader/loader.conf and saved my changes then I ran my modified update alias. After running it I mounted the EFI partition on /boot again and looked at /boot/loader/loader.conf. It now contains the comment from the backup file so it works! I no longer need the fixboot alias so I removed it from ~/.bashrc. The real test will come when an update is actually available or perhaps when I change kernels. In any case, for now I consider my problem solved. If I’m wrong about that I’ll update/reply to this thread at that time.

I hope you find this useful,

Ernie

1 Like
2

Hi @ernie, :wave:

thanks for providing us with your very detailed and interesting article. :+1:

Just want to add the following:

Users of the fish shell can do it this way:

  • use functions for that; you can still use the alias command for definitions
  • after defining a function save it with funcsave to make it persistent

example:

if you have exa installed (“a modern replacement for ls”)

alias yy="env EXA_COLORS="da=33:di=35" exa -lg"
funcsave yy

BTW:

The command functions shows all available functions/aliases for the fish shell.

For more: see man pages

Many greetings from Rosika :slightly_smiling_face:

1 Like
3

Thank you for providing an alternative to using aliases albeit by using a different shell. Your comment will be useful for others who use the fish shell, or are interested in trying out an alternative to bash. I’ve experimented with it (and ksh, csh, zsh, etc.) at varying points in my GNU/Linux journey, but none of them were quite ‘my cup of tea’ so I have always reverted to my long time standard, the bash shell. I’m familiar with it. It meets all my needs. It’s easy for me to use. It’s the default shell on most of the distributions I’ve used, and Learning resources for it are more than abundant on the Internet.

This is going a bit off topic, but my decision making process across my life has been largely influenced by my Step-father. When I got my first car (circa 1967/8), it needed new (drum) brakes so he taught me how to change them. While we were working on the brakes, he told me “Always remember, if it ain’t broke, don’t fix it!”, meaning that I shouldn’t go ‘fixing’ things just to be fixing them. That car had an in-line six cylinder engine with a 2-barel carburetor. The benefit of changing that carburetor to a four-cylinder or three two-barrel carbs (known as a 'six-pack back then) would be outweighed by the cost of the parts combined with the time and effort involved in making the upgrade/changes. With that statement, he taught me to ‘look before I leap’ and to consider my decisions before committing to them. He was an excellent father figure, and his advice has served me well across my life.

My2Cents,

Ernie

4 Likes