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.
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,