• Linux
  • November 2018
    M T W T F S S
    « Oct    
  • Meta

  • Follow me on Twitter

  • Advertisements

Script to create scripts

I’d been playing around with sed in scripts to modify and insert licenses into scripts and source code and even set up a script to insert a basic header into existing scripts. Last night, the idea of writing a script to create the foundation of a script – the hash-bang and a basic header.

This morning I sat down and wrote the script. I started with checks for the arguments. I didn’t want a new script overwriting an existing one and I wanted to make sure that something was passed to give the new script a name.

Then I used sed to modify a header template, filling in information such as the name of the script, the author and the author’s email. I was able to get sed to append the modified header into the file like I did with my license script. I used the cat command to concatenate it. It works.

Once the script foundation is created, I delete the temporary header file and give the new script execute permissions. Then I give the user the option to open the script in nano for editing or displaying it using cat.

The output is as follows:

# Script Name :testscript.sh
# Description :
# Dependencies :
# Arguments :
# Author :Richard Romig
# Email :rick.romig@gmail.com


Conky & Broadcom WiFi


Not too long ago, I came across an HP EliteBook 2560p and thought it would be a nice little laptop to carry around because it was small and lightweight. It’s a bit bigger than the HP 110-Mini Netbook and more powerful with a second generation i5 processor, 8GB of RAM and a 320GB hard drive.

Naturally, I installed Linux Mint 18.3 with the Cinnamon desktop environment. It runs quite well. I had to install a driver for the Broadcom wireless adapter and I took the one that Mint recommended, it works just fine. The only problem I noticed was that my Conky script wasn’t displaying the wireless signal strength. I checked the script to make sure I had the interface name correct and it was. Tonight I searched Google for the problem and learned that sometimes Broadcom wireless adapters block Conky’s requests to get the information from the adapter.

The fix is to run the following command to give Conky the needed permissions:

sudo setcap cap_net_raw,cap_net_admin=eip /usr/bin/conky

To see what permissions Conky has:

getcap /usr/bin/conky

And to remove the permissions:

setcap -r /usr/bin/conky

Restart Conky, log out and log back in, or restart the computer and you should see the WiFi signal strength.

Tweaking scripts

Linux-works-for-youI fiddled around with a couple of my scripts yesterday. I made a couple of minor tweaks to my Getinfo script. I changed the variable that holds the filename that the information gets written too so that the file gets written to the logged in user’s home directory. Originally it was written to the current working directory. Rather than build the path and the filename using the += operator, I assigned it all to the variable at one go: infofile=”/home/$USER/$HOSTNAME.info”.

I also tried to write a more elegant version of my randpic.sh script which randomly selects a sub-directory in my Pictures directory and then picks a random file from that directory. I do have a few image files (wallpapers) in the root of the Pictures directory so now and then one of them will get selected as a directory and when the next part of the script tries to grab a file from this “directory” I get an “invalid file” message and the script runs through the loop and tries again. It really doesn’t bother me since these particular files are wallpaper images that can be disregarded for my purposes.

I thought about ways to test whether or not the selected directory was, indeed, a directory and if it wasn’t, to either process the file or to disregard the selection and try again. I tried nesting either a while or an until loop but I either ended up with an infinite loop or it kept selecting files from the same directory. In the second case, I saw that with each iteration of the outer while loop, it would add another “/” between the path and the filename when it displayed the selected file. I don’t think it actually affected the actual operations on the file, only how it displayed in the terminal.

I finally gave up on the idea although I would like to eventually figure it out. But I did make a couple of tweaks to the original script. In the case statement, I added a choice to quit the script and break out of the loop. Now “Y/y” accepts the selected file and breaks out of the loop while “Q/q” rejects the file and breaks out of the loop. Any other key rejects the file and continues the loop to select another directory and file.


Non-interactive script messages

I’ve got a couple computers that are running most of the time but I don’t actually get on them regularly so I placed a script to run updates  in /etc/cron.weekly. The script creates a log file in my home folder so I can look and see if there were any errors. I noticed the following lines in the log files:

z-update log #1
debconf: unable to initialize frontend: Dialog
debconf: (TERM is not set, so the dialog frontend is not usable.)
debconf: falling back to frontend: Readline
debconf: unable to initialize frontend: Readline
debconf: (This frontend requires a controlling tty.)
debconf: falling back to frontend: Teletype
dpkg-preconfigure: unable to re-open stdin:

z-update log #2
debconf: unable to initialize frontend: Dialog
debconf: (Dialog frontend will not work on a dumb terminal, an emacs shell buffer, or without a controlling terminal.)
debconf: falling back to frontend: Readline
debconf: unable to initialize frontend: Readline
debconf: (This frontend requires a controlling tty.)
debconf: falling back to frontend: Teletype
dpkg-preconfigure: unable to re-open stdin:

The messages appeared following the execution of apt-get dist-upgrade. The updates seemed to have completed without error but these messages merited further investigation. I also noticed the same sort of messages when I watched the progress of updates done with Mint’s Update Manager.

It appears that the command was expecting some king of user interaction even though I’d include the -y and -q flags. My research indicated that setting the DEBIAN_FRONTEND environment variable to “noninteractive” might solve the problem so I changed that line in the script to read:

DEBIAN_FRONTEND=noninteractive apt-get dist-upgrade -yq 2>> $LOGFILE >> $LOGFILE

I checked the log file on one of the computers after the script’s scheduled run this morning and saw that the messages did not appear. Apparently, the fix worked. I can’t say this would work for others. The computers on which the messages appeared are both running Linux Mint 18.3.

A locale fix & an install script

When running updates on my Linux machines, I’d been seeing an error message in the terminal when update-initramfs ran — “Warning: No support for locale: us_US.UTF-8” It didn’t seem to be affecting anything but my curiosity about reached its limit and I googled it. The warning message appears because /usr/share/initramfs-tools/hooks/root_locale  is expecting to see individual locale directories in /usr/lib/locale,  but locale-gen is configured to generate an archive file by default.

The solution was simple – just two commands:

sudo locale-gen –purge –no-archive
sudo update-initramfs -u -t

Since I’d been seeing the warning message on all of my Linux systems, I put the commands into a bash script. Easy fix.

[12 July 2018 edit: I added the two commands to the scripts I run after a fresh install of Linux Mint since I know that locale-gen will, by default, generate locale-archive and cause the error when running update-initramfs. It seems like a good time to apply the fix.]

When I ran the script on the Latitude E5500, I get an error indicating the drive was full. I’m not sure how I managed to fill it but for all intents and purposes, it was. I had originally set it up with root and home both on a single LVM partition so I figured it was a good time to reinstall Mint on it while dividing the drive into three partitions – root, swap, and home.

Once I got Mint reinstalled, I tested a script I’d put together to install a few utilities, applications, services, and tweaks. Parts of the script worked while other parts of it didn’t so there were some things that I had to individually install. I’m looking at the script and seeing if I can tweak it some and determine why some things didn’t install.

I’m probably going to reload my Dell Latitude E6500 soon which is also set up with an LVM partition. I’m also thinking about reloading my Lenovo M91p desktop. It’s partitioning is a little funky too, essentially a 500GB Windows 10 partition and a Linux partition. I’ve had the system for a little over six months and I’ve never booted into the Windows partition and I don’t think it’s likely that I will. Maybe there’s a way I can move the Windows to another drive. It’s just the installation file. I’ll have to look into that.


Last month I mentioned that I was working on conkyinfo.sh, a script to gather the device information I needed to use in my conky scripts. Now that I’ve found that my old scripts don’t work so well anymore, I’ve adapted a simpler script that shows less information.

But that doesn’t mean that I’ve tossed that script completely aside. Yesterday, I got to thinking about expanding on that script and gathering some basic system information into a text file stored in the home directory. It turned out that I really didn’t use much from the conkyinfo.sh script.

I set up variables to hold the results of dmidecode commands for general information about the system such as manufacturer, product name and version, and system serial number. I started out using dmidecode to get the CPU model and it worked well with the HP laptop I was using when I originally wrote the script.

While testing it on my desktop PC and my other Linux laptops, I noticed that on my Dell laptops, dmidecode returned ‘Not Specified” for the CPU information so I turned to using grep with the lscpu command to give me the information that I needed. I used grep and awk with /proc/meminfo to give me the amount of physical memory in gigabytes.  All this information was redirected into a file.

For information network interfaces and power (batteries), I redirected the output of the ls command on /sys/class/net and /sys/class/power_supply. For hard drive information I redirected the  lsblk output to the file. At the end of the script I ran the cat command on the file to display everything.


The only problem I’m having is when I run it on my Lenovo ThinkCentre M91p. The variables containing the output of the dmidecode commands all contain an error message: “Invalid entry length (16). Fixed up to 11.” I’m not sure what’s causing it but from what I’ve read about the error, it may have something to do with using sudo with dmidecode. Some articles talked about the host name being too long but even after shortening the host name, I still got the error. Some of the other computers have longer host names. but the error doesn’t occur. I’ve only seen the error when using sudo with dmidecode on the M91p.

Testing on the various machines using ssh and rsync made the process so much easier. With each changed to the script, I had to upload it to each machine and using a script makes that process so much easier when I can upload to all machines with one command.

SyncAll script & SSH

I’ve been watching the EzeeLinux videos by Joe Collins at EzeeLinux.com and I’ve been learning a lot from them. I recently watched one in which he talked about a SyncAll script he wrote that uses rsync to synchronize a set of folders among all the computers in his home network. It occurred to me that our network environments were very similar so I reached out to him and asked for a copy of the script.

Modifying Joe’s script to fit my network and situation wasn’t all that difficult. One change I made to the script was to set a variable to hold the first three octets of the IP address so that if my networking environment changed for some reason (i.e., a new router) where it changed from 192.168.0.x to 192.168.1.x, I’d only have to make the change once in script.

It was by watching Mr. Desktop & Mr. Server Episode 5 | Linux Networking & Connect2SSH that it all came together for me. That video helped me to get SSH set up on my Linux computers so that the script would work properly. The video also introduced me to SCP (Secure Copy) and SSHFS (SSH File Share) which will prove to be very useful tools.

I’ve assigned static addresses to all of the wired connections, something I’d been thinking about doing for some time. I’ve still got a couple Windows PCs on the network but for now I can deal with them through SMB shares, Dropbox, or Sneaker-Net. If necessary, I could install Linux on the Windows box I just replaced and set up SAMBA on it.


%d bloggers like this: