How to Rig Barrier for "Silent Running" on Startup

 I looked the web over but couldn't find a definitive answer to this question. The default, once you've installed Barrier, is for it to pop up a GUI (Graphical User Interface) box where you can set your configurations. But no where in that window is there an option to set Barrier to not show the window upon startup, leaving one to close out the box on each startup or reboot of your computer.

Or is there such a setting? Well, I happened to stumble across it at one point, and the great thing is it works! And the other great thing--especially for terminal-phobic Linux users (can there be such a person?)--is that it can all be done through the GUI. In other words, no terminal commands needed!

That was part of my problem, in that I was led astray in my online searches for this answer by people attempting to use complicated command line syntax. So, since I tend to prefer the terminal, I was looking for a command option I could use, but failed to find one.

So, this is my definitive answer of how to set Barrier for silent running on startup.

1. First, you'll need to have the Barrier box/window open on your computer. If it isn't already up, you can right-click on its system tray icon and select "Show" from the pop-up menu, that is assuming you've already started barrier. If you haven't, then start it from your system's menu and the window should appear.
   
   
2. Next, left-click on the "Barrier" menu item in the top-left corner of the window. Select "Settings" from the menu that is shown.
   
   
3. Then, you'll see two boxes that probably do not have a check-mark in them, which are labeled: "Minimize to System Tray" and "Hide on startup." Put checks in those two boxes and click on OK.
   
   
4. Note: on the newer version of Barrier, you'll also see a third box labeled: "Start Barrier on startup." Click that box as well, otherwise it will not start up, you'll have to show the box and click the start button to activate it. Also, to have it autostart upon login, you'll need to put it in your system's autostart settings or folder, at least in Linux.
   
   
5. Once again, left-click on "Barrier" in the menu, but this time select "Save configuration." Select a directory and a file to save your configuration into and click on SAVE to save the configuration you have changed in settings.
   
   
6. Now, reboot your OS to test out the new settings. It should no longer show you the box, but it will show an icon in the system tray, which will enable you to show the widow again, quit, or other options.

Yep, its that easy! Enjoy.

How to Use a Downloaded Bash File

I have a web page of mostly bash scripts located at: https://nlgg.rlcopple.com/index.php?currdir=&currfile=Download+Scripts.php

On that web page is a link to this web page with the promise of how to use those scripts, for those new to Linux or have never dealt with it before. So that is what you will find here, a post on how to use a bash script that you downloaded from my site. It would apply equally as well to other downloaded bash scripts.

Step 1 – Download the File

First, of course, you will need to download the desired script. The easiest way is to simply click on the link. But if it displays the text of the script instead of downloading the file, you can check the contents of the file that way, but saving it in a file on your computer would require you to copy the text, then paste it into a text editor, then save the file, giving it a name.

So, for most folk, the best way is to right-click (that means to hover your mouse over a target and then press down on the right mouse button instead of the left), then in the pop-up menu that should appear, you should select the option that says something similar to, “Save link as . . .” which will then, when clicked, will download the file to your hard drive. Make sure you remember where you put it and the name you gave it, if you changed it from the default.

Step 2 – Check the Contents of the File

This is the step most tend to skip. Why should you look the file over? 1) To identify any potential problems. Even if you feel you don’t have the chops to figure out the coding on a bash file, most of the commands are obvious, like “echo” means to copy the string of text to your terminal window. But there are other more practical reasons.

Frequently, a bash script file will have what are called comments in them. These are text preceded with the hash sign: #. Any comments in the file will tell you two basic things: 1) What the coding is meant to do, and 2) any instructions on how to use the script file. For instance, in my Install programs script, you will want to look over the list of programs it will install from repositories and flatpaks and adjust them to your liking.

Step 3 – Make the File Executable

The next step is to make the downloaded file executable. In Windows you generally accomplish that by including the correct file extension such as *.exe, *.msi, *.bat. Of course, the file must match the extension to work. But that isn’t the way to “mark” a file as executable in Linux.

Perhaps the easiest for new Linux users is to locate the file in your file manager, right-click the file to bring up the pop-up menu, Then select “Properties”, then the “Permissions” tab, then locate the text which says something to the effect of “make this file executable.” Click that box and click OK.

Or, if you want to use the command line in a terminal, you simply enter the following line and at the end of it, press Enter:

chmod +x [name of file]

Step 4 – Running the File

You can run a bash script file at this point. However, unless you saved it in a directory that is included in your PATH, you would run it by including the entire absolute path. For example, let’s assume we have a bash script file we’ll called “laughatme” and that we have already marked it as executable; and we have put the file in the bin directory under our home. There are three ways to run the file.

Method 1

You can run the file using an absolute path. So if we wanted to run the above mentioned bash file, I would enter the following command from any directory in a terminal window.

/home/$USER/bin/laughatme

In some distributions you may need to put “bash” before the line for it to work.

Method 2

If you are already in the directory where the bash file is at, or if you change to the directory where the file resides, you can enter the following shorthand:

./laughatme

Method 3

The easiest way is to put the directory as part of your path statement. Your path variable holds all the directories that your system will look for any program you tend to use from the command line. Each directory is deliminated by a colon - “:”.

To check which directories are in the $PATH variable, enter the following command in a terminal:

echo $PATH

Generally, you will see where most programs are put: /usr/bin being the most common. Other directories you may see are: /bin:/sbin:/usr/sbin. On occasion, some distributions will check if there is a bin directory in the user’s home directory, and add it into the path. If wherever you put the script at is not in one of the directories listed in the path, then you have two options:

1) You can move the bash script file to one of the directories listed.

If you use this method, it is best to put scripts like this into a home directory file. Those are any directories that begin with “/home”. If you do put it into a system directory like “/usr/bin”, then you will probably want to change the ownership of the file from your user name to “root.” Assuming the directory you are in contains the file, you would enter:

sudo chown root:root laughatme

Another common place to put scripts aside from $HOME/bin is $HOME/.local/bin

2) Add the directory it is in into the PATH variable.

In my example above, I would add the following command to the end of your .bashrc file in your home directory:

[[ -d $HOME/bin ]] && [[ $PATH != *”$HOME/bin”* ]] && export PATH=”$PATH:$HOME/bin”

That is a simplified IF/Then statement in bash. So if there exists a valid directory of “bin” in the users home directory, and the directory is not included in the PATH variable, then and only then will it add the path to the $PATH variable.

Once the path has been added to the $PATH variable, then you should be able to simply enter the name of the script file no matter what directory you are in (you may need to close out your terminal window and open a new one to activate the new path statement):

laughatme

That is it! You are now ready to use the script file, enjoy!

My ASUS ROG Falchion Mechanical Keyboard Keeps Shutting Down My Linux Computer

I recently purchased a great keyboard for my Linux systems. It is a wireless mechanical keyboard. It is designed with gaming in mind, though I don’t intend to use it for that purpose.

It has one glitch,however. Its power saving feature causes the keyboard to power off/restart/or hibernate your whole system after 2 minutes is up. I did some Internet searching, and this workaround to disable the power function worked for me on x11.

1. You need to edit the following file:

sudo nano /usr/share/X11/xorg.conf.d/40-libinput.conf

2. You’ll need to append the following lines to the end of the file:

Section "InputClass"
     Identifier "disable asus falchioh sys control"
     MatchIsKeyboard "on"
     MatchProduct "ASUSTeK ROG FALCHION System Control"
     Option "Ignore" "on"
EndSection

3. Save it and reboot. That should fix the issue for Xorg.

For Wayland, you'll need to do the following:

1. You'll need to create the following file in its directory:

sudo nano /etc/udev/hwdb.d/99-asus-falchion.hwdb

2. Copy and paste the following into that file: 

evdev:input:b*v0B05p193Ee0111*
  KEYBOARD_KEY_10081=reserved
  KEYBOARD_KEY_10082=reserved
  KEYBOARD_KEY_70070=reserved
  KEYBOARD_KEY_70071=reserved
  KEYBOARD_KEY_70072=reserved
  KEYBOARD_KEY_70073=reserved
  KEYBOARD_KEY_70074=reserved
  KEYBOARD_KEY_70075=reserved
  KEYBOARD_KEY_70076=reserved
  KEYBOARD_KEY_70077=reserved

3.After saving the file, run the following command:

sudo systemd-hwdb update

Then reboot into your Wayland session and you should be good to go!

Update to Post: Setting Up an Operating System with a Home Directory on a Separate Disk

In my last post, which was a while ago, I went over how I installed Peppermint OS onto my Acer Aspire laptop. On that article, I had some instructions on how to do it that I need to update.

The issue was, whenever I edited the /etc/fstab file and mounted it with the old home files on that disk by rebooting, the new distro’s desktop would be replaced with the last instance of the desktop look, feel, and panel/dock that I had on the previous install of that desktop environment’s config files. But I figured our a way that is more efficient than what I presented the last time. Here are the main changes that I have to offer to what I wrote in How I Installed Peppermint OS PCNetSpec Edition onto a Computer with a Separate Disk as the Home Directory

You should do these steps before you update and upgrade the system. One of the first things you should do is to edit the fstab file in the /etc directory, before much changes happen to your current home directory after an install. It doesn’t matter whether you do these steps before or after you edit the fstab file and set it to use your drive for a home directory. If you do edit the fstab file before you do this, just make sure you don’t reboot until you’ve done the following steps:

After mounting the old disk on /mount/rick/myhome as instructed in the second set of steps, look for point #4 of the above referenced article, go to the config directory where your desktop files are configured. This is normally at ~/.config/(desktop directory). If you are doing this on a peppermint install, that would be the XFCE DE. But I believe these steps would work for most DEs, However, I’ve only tested this on XFCE thus far. Note, I will use my own disk’s label and directory below. Make sure you use your own directory for your setup. Enter:

cd /media/$USER/myhome/$USER/.config

cp -r ~/.config/* ./ This will effectively copy all config files over to your disk myhome mount.

With that steps done, you are now ready to reboot into your system, assuming you have already edited the fstab file to mount the new disk to /home. Otherwise, you’ll need to edit and add the disk info as detailed in the above article to switch your home directory to the disk it is on. Then you will be ready to sudo reboot!

That’s all you have to do to save the settings on a newly installed distro with an XFCE desktop environment.

Also, in my original article, I have some instructions on how to access the blkid app when it isn’t in the path of the user, by adding that path to the users current path variable, which you can check by entering echo $PATH into a terminal.You will be looking for the /usr/sbin directory, specifically, that is where the program resides.

Or, you may wish to not add that directory path to the $Path variable. You can still run the program by adding “sudo” to the beginning of the command, like this:

sudo blkid

Enter your password in and then it will run the app and you can do the same to reboot the computer from the command line in a terminal--sudo reboot or you can use the DE’s logout function.

If you did not run any of the programs on your new system, the files you copy from your “new” home directory will be the settings for the current desktop environment to your “old” home directory. will overwrite past settings for the specific distro onto your soon-to-be home directory, thus preserving the distro’s settings. If you wish to save certain settings from your old home directory, I would suggest copying the whole .config directory to a backup directory:

mkdir ~/.old-config && cp -r ~/.config/* ~/.old-config

You can, of course, use whatever naming scheme you wish for the backup directory.

Then proceed with the home directory instructions and your own tweaks to the system.

How I Installed Peppermint OS PCNetSpec Edition onto a Computer with a Separate Disk as the Home Directory

. . . and kept the original Peppermint settings once I linked my home drive on the alternate disk.

Yep, that's the setup I have on my Acer Aspire 5 thin laptop (using a AMD Ryzen 3 cpu and a AMD Radeon GPU). I have a 119 GB nvme drive, and an alternate SSD drive of 1 TB. I bought that drive once I realized my computer had a spot for it when i was installing more memory in it. It was then that I had the "brilliant" idea of using that spot for my home directory, especially since I was afraid that the nvme card wouldn't be big enough to hold my whole home directory plus system files. So I ordered and installed the drive. I followed some directions on the Internet on how to move my home directory to a separate hard drive. I successfully had a system that gave me plenty of room to expand on both the system (119 GB) and on my home directory (1 TB). Plus, I have a 2 TB external drive which connects via USB for doing my backups.

Now, I had, at the time--after a period of distro hopping (that is a term for anyone who regularly installs new Linux, or other kernel/systems such as BSD, on their computer because of various reasons), looking for a distribution that would work best for me--installed Neptune OS, which uses the KDE Plasma desktop environment (DE). I used that distro for around one year before I decided to distro hop again. If I recall correctly, the first distro hopping I did on this laptop, was in the following progression: Peppermint OS (had a problem updating), Sparky Linux (couldn't get it to install correctly), Garuda Linux (it broke down on an upgrade), Linux Mint Debian Edition (mostly as I needed a stable system and I knew it would work) and a few others I don't recall right now. Somewhere in that first distro hopping period, is when I started using that extra 1 TB drive.

There are several posiitives to doing it this way, but the biggest one is: All of your user settings for the various programs you use are retained upon installing a new distro. For example, upon reconnecting my home directory to the new computer system and opening up my fresh install of Brave or Firefox browser, all of my settings and bookmarks are just as I left them. I was even still logged into my Google account!

Likewise, the main downside is that all of my user settings were retained. Which was a negative when after installing a new distro with, for example the XFCE DE, I would set up the DE like I would want it. But when I connected my home drive to it, all my settings would revert to a previous distro's XFCE's configuration. That actually happened when I first installed Peppermint OS on the Acer, as soon as I connected with my home directory, the panels, theming, wallpapers, all switched over to a previous install of an XFCE DE I had when I ran for a time OpenSUSE, with all its keybindings (the good thing) and all of its inherent problems like the settings for the display not sticking, that is, not being saved and reloaded on a reboot/restart of the session (definitely not a good thing).

So, when it came time to do a fresh install of Peppermint on the system, I decided I wanted to try something I'd not done before. My usual process after installing and updating the system and programs was to reconnect my home drive to the install. "How?"

1) Open a terminal bash session and type:

lsblk

. . . to identify the device location of the home drive. Helps ensure that I've got the correct drive.

2) I then run the following command:

blkid

This will give you a list of the drives and partitions on your disks, but the key part you are looking for is the partition where your home directory is residing. You should be able to see the UUID sequence of letters and numbers in groups of four. It will look something like: xxxx-xxxx-xxxx-xxxx-xxxx. You'll want to mark and copy just the number/letter combination using your mouse to mark the text and holding down the Ctrl and Shift keys at the same time, then pressing and releasing the "C" key. That key combination is usually represented as Ctrl+Shift+C.

If you are on a Debian-based distro, or Debian itself, you may not be able to find the command on your computer. While it is often there in /usr/sbin, it is only that the command's path isn't in the user's path environment variable. To correct that, type in the following command into the terminal:

export PATH="/usr/sbin:$PATH"

It will only last until you close the terminal. To make it a last beyond that terminal session, enter the same command in the .bashrc file, or one it includes. Now, if the program is there, it should show up.

3) Now, I edit the fstab file in the /etc/ directory using your favorite text editor--I tend to use nano since it is on most systems. The purpose of the fstab file is that it will tell your operating system where to mount and find your system, boot files, as well as any other directories such as the one that we just created in our example above.

sudo nano /etc/fstab

4) Then I make an entry for attaching my home directory upon bootup:

I enter "UUID=" then I paste the number/letter that I copied in step 2 above by again holding down the Ctrl and Shift buttons, but this time pressing and releasing the "V" key. Press the spacebar or the tab key, then enter "/home" which will tell the system where to mount the drive. After another space or tab, you'll enter the filesystem it uses, which in most cases will be ext4. Then you'll enter some flags or commands that tell what the drive will do. So after another space or tab, enter "default,noatime", followed by a "0" and a space, then a final 0. By the time you're finished, you should have something that looks like the following, with, of course, your specific UUID code in place of the x's:

UUID=xxxx-xxxx-xxxx-xxxx-xxxx /home ext4 default,noatime 0 0

You'll notice that the pattern matches that of the other drive as well. Once entered, save the file by pressing and holding the Ctrl key, then press the "S" key. Now you are ready to exit the file by once again holding down the Ctrl key while pressing the "X" key.

5) Then, to activate the switch to the new home directory, you'll need to reboot. Once you've done that, you should have access in your home directory to all the files you had on the disk before. The advantage of this is big, in that while I would recommend backing up your home directory, just in case you over write it with your new system you're installing, there is no need to restore your home directory's files from a backed up copy. Plus, as I've already mentioned earlier, you'll automatically have all your user settings for your programs. So, if for instance, if you use Thunderbird as your email client, you won't have to reset up your email accounts again. It's as if you never switched systems.

So what did I do differently to fix my other problem?

1) Certainly before step # 5, but you can do this at any point after you install and update a new system, I'll first create a temp mount point for the old home directory.

For Debian and systems based on it, you'll enter:

cd /media

For Arch and most other systems save a few, you'll add a "/run" directory so that you'll enter:

cd /run/media

2) Then you'll need to create a directory for your user

sudo mkdir $USER

In my case, it would create the directory "rick" so it would read /media/rick

3 ) However, you'll need to change the ownership of the user's directory to the user, so you would enter:

sudo chown $USER:$USER $USER

4) Then you would create the mount point directory inside the user's directory:

cd $USER && mkdir /myhome

5) Then we would mount the directory:

sudo mount /dev/sda1 /media/$USER/myhome

or on non-debian-based systems:

sudo mount /dev/sda1 /run/media/$USER/myhome

Of course, you can name the mount directory anything you desire, within reason. Also, my home directory is on partition 1 of the disk, thus my /dev/sda1 entry. You'll want to put whatever drive and partition that your home directory is located in place of sda1.

What this does is it makes the soon-to-be home directory accessible to you before you mount it as your /home directory.

6) It is easier to do the next part in a file manager. Go into your newly mounted home drive, and go into the ".config" directory. If you don't see it, try pressing Ctrl-H. That will show all the hidden files. Those are all the directories and files that start with a period.

Once in, delete all the folders of past programs that you've used before or you no longer need. Don't worry here about removing something your system might need. Especially good to get rid of old DE directories like XFCE or KDE (which pretty much covers all directories and files that start with a "k"). The only config files and directories that should be remaining are of programs you are currently planning on using. 

For example, I have a file in the .config directory called kitty. it is a terminal application that I prefer using. But, if you fail to keep any config files, all it would mean is that you would have to start over setting up that program.

But the main thing is to delete or rename any desktop environment's configuration files, that will give your system a fresh "blank slate" to put its default setting into. If you don't find the setting file you are looking for in the $HOME/.config directory, check in your $HOME directory as a lot of programs will put their configuration files in there instead of the /.config directory.

Once I've done the above, I would then continue with the steps 1 - 5 above where ever you left off at. Once you've rebooted, you should log into your home directory with all your files intact, including the settings for your programs, yet it won't affect the desktop environment's settings in a bad way.

So, that is how I keep my desktop environment's settings while reusing my /home directory.

How to Deal with a "filter failed" error in CUPS

 I ran across this error recently when I installed a new Linux distribution on my writing computer called "Neptune OS", which is a Debian based distro. I spent about 2 days troubleshooting this problem, and I finally ran across the solution (at least in my case) that allowed me to print again.

So, installed this distro that I wanted to try out for my channel series: "New User Linux Reviews." I installed it, which went smooth enough, Then, in checking out the distro, one of the functions I check out was whether the system installed the printer (I have a network printer, a Brother MFC-L2710DW) or not, how easily it was to install it if it didn't, and did it work or not?

So when I went to check out the printer, I was pleasantly surprised to find the printer had been automatically detected and installed. So I initiated a test page print to see if it would print. Unfortunately, it didn't. And the only error message I found was "filter failed," which I discovered in my research could be caused by several different issues.

Probably the best troubleshooting guide that I found on the web was in the Arch Wiki:

https://wiki.archlinux.org/index.php/CUPS/Troubleshooting#CUPS:_%22Filter_failed%22 

It listed several of the major reasons it could give that error, as well as what to do about them, though it failed to give me a solution to my problem. Still, it pointed me in the right direction to figuring out, quite by accident, my solution.

After scouring the web for potential causes and solutions to this problem, and coming up empty handed, I realized that there wasn't much out on the web to help people address this issue (thus, the reason for this blog post). So after finding the Arch Wiki article mentioned above, I read through my error_log file in

/var/logs/cups/

That is when I discovered that the problem was an app called "pdftopdf" that it failed to create a "log file." Which created a cascade effect of other apps--that CUPS relies upon--to error out as well. Since some of those apps are also cups filters, it gave me the "filter failed" error in the print queue.

But, I still had to figure out what to do about it. After trying out a few other options, and they failed as well, I finally noticed one error message in the error_log file, which read: 

open /usr/share/cups/data/default-testpage.pdf: no such file or directory

On a whim, I decided to go to that directory and find out what was there. What I found were several pdf files that I realized were templates. However, what I also noticed was a file called

default-testpage.pdf.XXXXX

The "XXXXX" stands for some other letters that started with a "C" but I've already forgot exactly what they were (I'm not even sure about the "C" either). I wondered what would happen if I deleted  the extra letters from the end of that file so that it ended in "pdf," whether it might not find the file and print it. So I did that, then I went back to the printer queue and hit the "reprint" button: it printed!

Okay, so that meant that the CUPS system wasn't coordinating with what the printer was looking for as far as file names. I suspected it might be the CUPS system which was at fault, since I've had this printer for some time now, and have installed it on multiple systems without much issues, save for Arch distros, which while they install CUPS, rarely appear to have their daemon active, much less a GUI print manager application installed.

From that data, I wrongfully concluded that the two files I had noticed in that directory (default-testpage.pdf.XXXX, modified to default_testpage.pdf and file testprint which I had modified to testprint.pdf, were still there. I had assumed that these files were temp files that would disappear once they printed. I should have known better, however, that these were templates with names like "standard.pdf, secret.pdf, topsecret.pdf, classified.pdf and unclassified.pdf just to name a few of the other files in the directory.

However, what caused me to realize that bit of truth were the messages that now popped up on all three of the printers I had installed on the system that said something about a missing file, in bright red at the top, and they failed to even acknowledge that I had printed a test page, nothing in the print queue, nothing in the error_log file save something about not being able to create a profile or something along those lines. That is, once I deleted those two files.

So, what was I to do? That's when I wondered if my Linux Mint CUPS folders on my laptop might have the same list of files, like, maybe I could use those files? So I checked and they did have those same files. So I copied them all over to the same directory on my desktop, and guess what? Suddenly, the printers worked!

All I can figure was that one or more of those files were corrupted and/or the printer was looking for names that CUPS had given different names to use as templates. Not finding the expected template pdf file, it crashed. Once I changed the name of that one file, the printer was able to print the file. In copying over the files from a working copy of CUPS in this directory only, I somehow fixed the system.

So for everyone out there who has the same error in the error_log file, that could be your issue and solution as well.

May the Linux Force be with you!

 

UPDATE (3/14/21): I reinstalled the system and here is the file I noticed with the extra ending on it in the PDF templates that are in the /usr/share/cups/data directory:

default-testpage.pdf.distrib

I also printed out a normal text from the Kwrite program successfully, before I ever changed anything. The printer works out of the box. The only part that doesn't appear to work is the test page which should print out when you select "Print Test Page" under the maintenance button on the "Printers" section of the System Settings.

Once I had confirmed that everything else would print, I removed the ".distrib" ending so that the file read: default-testpage.pdf, which is exactly the file name that the error log said CUPS was looking for. Once I made that one change, it would print the test page just fine.

So, the bottom line is that to fix this apparent error, all one has to do is change the file name from:

default-testpage.pdf.distrib

to:

default-testpage.pdf

And you'll be good to go!

You can do that by entering the following command at a terminal prompt:

mv /usr/share/cups/data/default-testpage.pdf.distrib /usr/share/cups/data/default-testpage.pdf

May the Linux force be with you!

How to Use a Bash Script File

 A Bash script file is simply a file containing a list of commands as one might enter from a terminal command prompt, with the addition of some more programming options like If . . . then, for, and while statements. It can be made to do most any function on a Linux, Apple, or other Unix based operating systems. They can greatly simplify and automate certain tasks.

For example, on a Debian based system, to preform an upgrade from the terminal requires entering at least two lines of text-based commands into a terminal. First, one must do an update to update the repositories to ensure one has all the most recent changes to them. Then you accomplish the upgrade, so the terminal commands would look like this:

sudo apt update
sudo apt upgrade

To create a bash file, you open your favorite text editor and give it an appropriate name, like in this case we might name this file "aptup.sh"

Note, the "sh" extension is commonly used for bash script files, but unlike MSWindows, that doesn't make it executable for Linux. You could put any extension on there you want, or none at all.

Now, enter the following to create the bash file:

#!/bin/bash

# This is a script file to make updates simpler!

sudo apt-get update
sudo -y apt-get upgrade

exit

The first line is the same for every bash file. It essentially tells the system what program and where it is at that will run this file.

The second line is optional. It is a comment. Every line that begins with a # will be ignored by the bash program, except the very first line, of course. But it is a good practice to put a general purpose statement at the beginning of your file, if for no other reason, if you forget what this file does, it serves as a good reminder for you, and provides any introductory information for others who might look at your source code. You can put as many or as few comments in a file as you want, put them anywhere you desire, or none at all. As long as a line has a # before it, it will not be run by the system. As a matter of fact, putting a # before lines of code is a good way to not have them run without deleting them entirely.

On the update and upgrade commands, you'll notice two changes I've made from the initial "apt" commands above. First, I've used "apt-get" instead of "apt". Apt is designed to be run interactively by the user, where as apt-get has provisions for running inside a script.

The second change is adding in the -y option. This option allows the script to become more automated by assuming a "yes" answer to any yes/no questions it asks. Typically, an upgrade script will list out the files it intends to upgrade, then ask you if you want to proceed with the upgrade.

The last line is optional at the end of the file, but it is good practice to put it in. It tells the bash script to stop processing and exit the file. It becomes more necessary if you want to stop processing earlier in the script, like during an if . . . then statement.

Once you have saved the file, there are a couple more steps to turn this into an executable file.

One, you should put this file into a directory that is in your path statement. To discover what is in your PATH statement, enter the following into a terminal window:

echo $PATH

Yes, it needs to be in all caps. Variables in Linux are case-sensitive.

What this does is it allows you to run the program no matter where you are in your directory structure. Otherwise, you would have to enter the full path every time you ran the script: /usr/bin/aptup.sh instead of just aptup.sh

The logical place to place this file is in your /usr/bin directory. That will make it available to all users of the computer and is where the bulk of user based programs reside. Or you can put it in a home directory and add that directory to your PATH environment variable by doing the following steps:

I usually create a bin directory in my home folder. You can do this using your file manager, but I'll show you here how to accomplish it from the command line. This is where I put all my scripts.

Bonus Info: In Solus, you don't have to add the user home directory bin to the path statement. If you create the directory, it automatically picks it up and adds it for you!

To create the bin directory ensure you are in your home directory by entering:

cd ~

Then enter (unless you already have one):

mkdir ./bin

Then to enter it into you path variable, enter:

export PATH=$PATH:$HOME/bin

If you run it from a terminal, it will only be good for the life of that terminal session. To have it come up every time a new terminal session is started, enter that command in your .bashrc or .profile file, whichever your system uses to initialize a terminal session. For Debian based systems, that will generally be .bashrc

Two, you'll want to make your file executable. Like the above, you don't have to do this, as long as you wish to preface every command with "bash" and the full path to where the file is, even if it is in a path where your system looks for executable program files. It is an easy command to do. Enter:

chmod +x ~/bin/aptup.sh

To accomplish the same in most file managers. right-click on the file and select "properties" from the menu. Go to the "permissions" tab and make sure to check off the box "make file executable" or something similar.

Now you should be ready to use your script file by simply typing in the name: aptup.sh! And your system will get updated by one command instead of two.