• Linux
  • May 2019
    M T W T F S S
    « Apr    
  • Meta

  • Follow me on Twitter

  • Advertisements


I had recently noticed that I was having problems downloading videos from YouTube using youtube-dl. In my investigation of the problem, I discovered that the version in the Ubuntu repositories for my Linux distributions was rather old so I went to https://yt-dl.org and followed their instructions for downloading the latest version.

After doing this, I found that when I checked the version number, it was sill the old version. Running which youtube-dl showed that youtube-dl was in the /usr/bin/ directory while the the curl command provided by yt-dl.org put the application in /usr/local/bin/.

Apparently, when installed through the Ubuntu repositories through apt or the Synaptic Package Manager, youtube-dl gets installed in /usr/bin/, so I ran sudo apt remove youtube-dl to remove the older version.

Then I created an installation script for youtube-dl which checks to see if youtube-dl has been installed to /usr/bin/ and if it has, runs apt remove to remove it. Then the script installs the application from yt-dl.org to /usr/local/bin/.

After checking /usr/bin/ and removing the version installed from the repositories, the script checks to see if there’s an installation. If youtube-dl is installed from yt-dl.org, the version number is displayed and the user is offered the chance to upgrade to the newest version. If it’s not installed, the application is downloaded to /usr/local/bin and the proper permissions are set.

I tested the script on several of my laptops. On some I installed youtube-dl from the repositories using the apt command, then ran the script. The script successfully removed the version installed by apt and installed the newest version from yt-dl.org. On other systems, I ran the script without the repository version installed.


My Mint-Fortune

The fortune and cowsay programs are kind of fun and in many Linux distributions you can have them launch when you open a terminal.

Mint 18.3 and 19.1 with the Cinnamon desktop environment both have an if statement in ~/.bashrc that checks for the existence of mint-fortune and will run it if it exists in /usr/bin as an executable file. I’ve noticed that MX Linux 18 also has this statement although it’s based on Debian.

The mint-fortune script does exist in 18.3 and is executable but there’s a catch. There is a setting for a key in a gsettings schema that must be set to true which is set to false by default. Mint 19 doesn’t have this gsettings schema or key at all.

In Linux Mint 18.3 MATE there’s a checkbox in Desktop Settings that sets the key to true. If you’re on Linux Mint 18.x Cinnamon (this may also work for 17.x or earlier), you can enable it with the following commands:

# Check to see if the com.linuxmint.terminal is present
$ gsettings list-schemas | grep 'com.linuxmint.terminal'
# If present, check if the show-fortunes key is present
$ gsettings list-keys com.linuxmint.terminal | grep 'show-fortunes'
# If present, check the value of show-fortunes
$ gsettings get com.linuxmint.terminal show-fortunes
# If show-fortunes is false, set to true
gsettings set com.linuxmint.terminal show-fortunes true
# Check the value of show-fortunes again
$ gsettings get com.linuxmint.terminal show-fortunes

Once the value is set to true, mint-fortune should run when you open a terminal provided fortune and cowsay are installed.

Linux Mint or other distributions running the XFCE desktop evironment will not have GSettings installed since it’s a Gnome feature. Linux Mint 19 Cinnamon doesn’t have either the GSettings schema or the mint-fortune script present.

I found a script in a Mint forum that has the same functionality as the packaged mint-fortune scipt and modified it a bit. All you need to do is place the script in /usr/bin and make sure it has execute privileges. You’ll need root (sudo) privileges to copy it.


function show_fortune {
  let "number %= $RANGE"
  case $number in

  let "number %= $RANGE"
  case $number in
  /usr/games/fortune | $command -f $cow

if [ -x "/usr/games/fortune" ] && [ -x "/usr/games/cowsay" ]; then

The script is nearly identical to the mint-fortune script that’s packaged with Mint 18.x and earlier but without the code that checks the value of the value of com.linuxmint.terminal show-fortunes.

I have written a script to install cowsay and fortune if they are not already installed. The script checks for the existence of /usr/bin/mint-fortune. If it exists, it checks for the GSetttings schema and the value of the show-fortunes key. If the script doesn’t exist it copies the script above into /usr/bin.

My Config Files

Over the past few months, I’ve seen a few ways to keep backups of my important configuration files. The idea of setting up a git bare repository interesting and I’ve seen a couple of ways to implement it but I haven’t done it yet.

What I have done is create a folder in a directory that get synced to all of my Linux computers to hold copies of my configuration files and I wrote a script to back them up to that directory on my main system. I consider the configuration files on my main system to be the master copies. Where there I variations I save them with an appended file name. For instance, I have three different versions of nano on my network, one for Mint 18.3, 19.1, and LMDE 3. Each of them supports different options and syntax highlighting.

Yesterday, I created a script to copy my modified configuration files into my home directory. The script is menu-based so it only copies the files I want. If I need to copy more than one file, it continues to offer me choices until I choose the option to quit.

I wrote functions to handle each configuration file option and made allowances for different versions of a file or special situations. In the function that copies the .nanorc, it checks the version of nano on the computer and copies the appropriate .nanorc file.

At the moment I two systems running Debian-based distributions, Linux Mint Debian Edition and MX-Linux. On both of these systems I’ve had problems with making sure my ~/bin directory was added to my path if I had logged in to the GUI login. Previously, I had gone into the terminal’s preferences and had it run as a login shell.

The function that handles the .bashrc checks /etc/os-release to see if the distribution is based on Debian or Ubuntu. If it’s Debian, after it has copied the .bashrc file, it appends it with two lines to check for the existence of ~/bin and add it to the path if necessary.

I haven’t thoroughly tested it yet but I’m certain it will work properly. I’ll proofread it and I might still tweak it a bit. Sometimes I see things differently when I put it aside for a while.

HomeBank Archive Script

I’ve been working on my script to creat monthly archives my HomeBank backup files throughout the month. (See Archive-Bank Update). The script has grown quite a bit from its original incarnation and become a bit more sophisticated and robust. I’ve added checks and streamlined the code. It’s been a good learning experience.

It recently occurred to me that other people who use HomeBank might find this script useful so I renamed it to hb-archive, polished it up, streamlined the code a bit more, and put in a function to display a help page to explain what the script does and give a general idea of how it works. That little page evolved in to a README file.

I had originally intended to include it in my Bash Script repository but I decided that since it is not a short utility script like most of my others, it should have its own repository. This morning, I created a remote repository on GitHub and pushed the script and its documentation.

Before pushing the new, polished version of the script to GitHub, I pushed my earlier versions first, to establish a version history and show its progression. In hindsight, I probably should have done that with my FnLoC project.

If you use HomeBank to manage your personal accounts and budget, you might find this useful. I’m sure the script could be easily adapted to work with other programs that create daily backup files.

Dropbox Adjustments

Dropbox recently began limiting non-paying accounts to linking their Dropbox to only three devices. I had a few more devices than the three allowed but since they’d been linked before March 2019, I was able to keep them but I can’t link any new devices until I’m under three again.

I checked my account and noticed that I had several linked devices which were no longer on-line so I deleted them. I am currently at four devices – my main Linux desktop, my Windows 7 machine, my HP laptop, and my HP mini with LMDE. I’ll eventually drop ether the mini or the laptop, maybe both.

This limitation in Dropbox availability is something I can live with for now since I can easily transfer and synchronize files over my home network and I’ve become less and less dependent on Dropbox over the last year. It’s still a convenient way to move files between my main Linux system and my Windows 7 computer even though SCP and SFTP are available through PuTTY and Filezilla.

I had been using my Dropbox as a convenient place to keep my password database since a Dropbox folder was common to all of my systems. I moved the database to a folder in my home directory that I synchronize with all of my Linux systems. On the Windows system, I still have it in Dropbox so I wrote a script to keep my password database synchronized between the two.

The script checks to see if one copy of the database is newer (e.g., I changed a password on the Windows machine) and copies the updated file to the other directory. I have it set up to run as a daily anacron job and keep a log in a hidden file in my home directory. To keep the log file manageable, it only keeps the last 15 entries.

I also keep a copy of my homepage directory in Dropbox. The homepage folder is where I keep a couple of html pages with links that I routinely access. The folder is synchronized on the Linux machines. On my Windows box I access it from the Dropbox folder. Eventually, I’ll find another solution such as moving it somewhere within My Documents and keeping a backup on a NAS device, using a batch file to keep my working copy up to date. I don’t make changes to the homepage folder very often so it’s not a priority right now. I do need to clean up the NAS and set up user account on it.

I suppose I could always keep those files in Google Docs. That’s an option. I can always access my files through the Web interface.

Archive-Bank Update

As I mentioned in Another cleanup script, I talked about writing a script to archive the backup files created by HomeBank. I’ve been working on it and improving it regularly over the past month.

Basically, the script sets up a temporary reference file with a timestamp set to midnight on the first day of the month and moves the backup files older than that to a backup folder, then places them into a dated zipped archive. (See the comments on the post for more detail).

Today, I added code to check to if the date is the last day of the month, which is the day I usually want to run it to archive the previous month’s backups. It it’s not the last day of the month, it prints a warning and asks me if I still want to run it. This feature will come in handy if I know I won’t be able to run it on the last day of the month for some reason.

Running the script on the first of the month will archive the previous month along with the month before that. The idea behind the script is to run it on the last day of the month to archive files from the previous month. For instance, I ran it on February 28 to archive my January backup files. Had I run it on March 1, I would have archived both January and February because the reference file would have been dated 1903010001.

Maybe I can set up the tests to look at a range of dates when it would be safe to run, maybe a five day window. However, if I were to accidentally archive the wrong month, I could easily extract the files back into the directory.

By the way, I came up with the idea and worked out most of the code whilst listening to my granddaughter’s high school band concert. Maybe it was the music that put me in the right state of mind and started the creative juices flowing.

Getting Ready to Rip

The other day I decide that I would finally set up a computer to “rip” music from CDs, tapes, and LPs to digital format. This has been on my to-do list for quite a while.

HP-800-G1-USDTI installed Linux Mint 19.1 Tessa on a refurbished HP Elitebook 800 G1 USDT into which I’d installed 16GB of RAM and a 750 GB hard drive. The installation when very well although I had to do a little tweaking of some of my software installation scripts. They’re working right now.

I installed Asunder CD Ripper, Audacity, Brasero, EasyTAG, Normalize-audio and HandBrake. EasyMP3Gain and mp3gain are no longer available in the Mint/Ubuntu repositories so I hope Normalzize-audio will do the job. I installed HandBrake so I can rip my DVDs (for backup purposes, of course). I’ll probably add additional software as I get going. It’s been a while since I’ve ripped cassette tapes (on an old Windows machine).

As I remember, ripping tapes was a laborious process. It took 45 minutes to record one side of a 90-minute tape to a WAV file, then I had to bring it up in an audio editor to break it into individual tracks before finally converting them to mp3 files. I doubt that the process has sped up much, if at all.

%d bloggers like this: