• Linux
  • December 2018
    M T W T F S S
    « Nov    
     12
    3456789
    10111213141516
    17181920212223
    24252627282930
    31  
  • Meta

  • Follow me on Twitter

  • Advertisements

BASH Scripts on GitHub

I created a second repository on GitHub for BASH scripts and I uploaded six scripts that might be of interest to others.

getinfo gets system information and places it in a text file located in the user’s home directory. The file includes:

  • Computer manufacturer, product name, version,, and serial number
  • Operating system
  • Amount of physical memory
  • System devices such as CPU model, graphics adapter, and network adapters
  • Battery information
  • Hard disk information to include model, serial number and capacity
  • Partition information

locale-fix.sh fixes an error that sometimes occurs during updates when you get the following warning;

Warning: No support for locale: us_US.UTF-8
The problem is that /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 fix purges the existing locales and tells update-initramfs to store locales in individual directories instead of an archive and then updates the locales.

ren-ext renames certain file extensions. Sometimes downloaded file have extensions in all caps or a different extension like .jpeg, JPG, or HTM.

  • The script changes extensions as follows:
  • BAK is renamed to bak
  • GIF is renamed to gif
  • htm, HTM, HTML are renamed to html
  • jpeg, JPT are renamed to jpg
  • MP3 and MP4 are renamed to mp3 and mp4
  • PDF is renamed to pdf
  • PNG is renamed to png
  • TXT is renamed to txt

renspace replaces spaces in filenames with underscores in a directory.

rmtilde removes backup files with a trailing ~ (tilde). I wrote this script after accidentally deleting an entire directory while attempting to type rm *~. While reaching for the ~ key, my finger missed the shift key and hit the Enter key, deleting the entire directory. Fortunately, I had a recent backup and I was able to restore my files.

upper2lower changes capital letters in filenames to lowercase. The script can be run on a specific file or it can be run against an entire directory. If run without an argument, the user will be asked for confirmation before renaming all file names.

A lot of the scripts I’ve written are for specific purposes but these seemd to be general enough to be useful to others. The scripts can be found at my GitHub repository.

Advertisements

FnLoC on GitHub

A few days ago I discovered that I had a GitHub account. I have no idea when or why I created it. I uploaded fnloc.deb to it but I really wasn’t sure what else I could do with it.

Yesterday I found a good video on GitHub for beginners. I took notes and following the instructions, I was able to create a git repository on my local machine and push it to my GitHub account.

I also found a couple of Markdown cheatsheets and reformatted my README file. I had separate readme files for the .tar.gz and the Windows packages, the main difference among them being the installation and removal instructions so I included them.

First I pushed version 2.2 (the version that introduced the singly linked list) as my initial commit, establishing a base version. Then I committed the changes for version 2.2.1 which is the current version.

FnLoC version 2.2.1 now displays the second line of a function header if it has been spit into two lines. The previous version accounted for such lines but only displayed the first line. I added a second variable in main() and in the data structure to hold the string containing the second line then set up a switch statement to consider the cases where the line being read is in the PosFunction state and the first character of the line is {, }, or white space and take the appropriate actions. In the function that displays the results, I put in a conditional statement to test if the second string was empty and, if not, print the string.

I’m still not quite satisfied with the way multi-line comma-delimited declarations, such as arrays and enumerated types, are counted. For example:


int daysMon[12] = { 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 };

is counted as a single line of code, as it should be. However, if the declaration is split into two or more lines, the program counts it as two lines of code (the first and last lines).


int daysMon[12] = {
    31, 28, 31, 30,
    31, 30, 31, 31,
    30, 31, 30, 31
};

To my thinking, the second example should be counted a one logical line of code. I’m pondering that problem and looking for a solution. I’m open to ideas.

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:

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

Lack of Linux

Lack_of_Linux

FnLoC v2.2

I’m not certain what version the program really is. I’d made several modifications to the original program some 20 years ago and apparently some of the early source code is missing. I know there was once a version 1.3 that listed the functions in the same order as they appeared in the target source code.

The last version was dubbed version 2.1.2 and since the code I finished today is so much different, I decided to make it 2.2. Maybe there’s enough difference to make it a major revision and call it 3.0. I don’t know.

I did some research and refreshed my knowledge of linked lists. Once I felt reasonably comfortable with them, I set out to implement a singly linked list to replace the stack. The primary motivation was to list functions in the output in the same order as they appeared in the target source code file. Using a stack (first in, last out), the functions were listed in reverse order.

A side benefit was that I needed fewer functions to implement the linked list since all I needed to do was to add data to the end of the list , display the output, and then free the memory when I was done.

In process of implementing the list, I simplified my data structures for holding the function data. Instead of a struct containing the data in main(), I used a couple of simple variables to hold the data until it was put into the list. Much easier to manage.

Most of the code for parsing a line of code and determining states was left intact since it was already working well. I did tweak the code for determining the possible states a function could be in because, for some reason, it would sometimes display main() with name of the next function encountered. The count would be right but the name would be wrong. Fixing the problem was a matter of changing one if condition. I’d been suspicious of that line for a while.

Finally, I split up the function that displayed the data in to three different functions, based on the the information they displayed. One prints a header to identify the program and display some introductory information. Next came the function that displayed the function data, if any. Finally, there was the function that printed a summary of the counts.

After testing it, I updated the documentation and the installation package (.tar.gz). The next step is to compile it in Windows and update the Windows package. I should be able to translate the Bash script that redirects the output to a text file into a Windows batch file without too much trouble.

Do I really want Linux to be mainstream?

Lately, I’ve viewed a lot of videos on YouTube about why Linux is more dominant on the desktop. Most of them seem to cover pretty much the same ground. Among the common reasons given are:

  • Too many distributions and desktop environments to choose from
  • A lack of standardization for Linux desktop environments
  • Lack of presence in the marketplace, particularly in retail outlets
  • Users don’t want to install their own operating systems
  • Difficult to use, high learning curve, change in work flow
  • Fear of the command line or the perception that the CLI is outmoded
  • Perception that Linux users are geeks and technically inclined
  • Lack of applications and games
  • Little corporate organization and sponsorship
  • Little effort/interest in the Linux community to make it mainstream

There are other reasons but these are the ones that immediately come to mind. I’d like to address them individually.

1. Too many distributions and desktop environments to chose from. I see having a multitude of choices as a positive. With Windows and Mac you essentially only have one choice. With Linux, you can use the distribution and desktop of your choice. If the one you choose doesn’t suit you, you can change it and if you set up your system right, you can make the change without losing your data. You can usually install a Linux distribution and be up and running in less than 30 minutes. It can be difficult to decide on a distribution so do some research. Download some distros, load them onto USB drives and try them out in a live environment from the USB drive. Or find yourself an old computer and test things out on that.
2. A lack of standardization for Linux desktop environments. I don’t see this as a big problem. The Linux kernel is standardized and while there are a few niche desktop environments, there are a few common ones such as XFCE, MATE, Gnome, Cinnamon, and Unity. There may be subtle differences in the way each of them work in different distributions, but they provide pretty much the same basic functionality. I don’t really see a need for a “standardized” desktop. I like the variety that’s available and having choices. Windows and Mac each have their own standardized desktop and and if you don’t like them, you’re stuck with them.
3. Lack of presence in the marketplace, particularly in retail outlets. This is a problem. The computer manufacturers don’t push Linux systems. Many of them have long-standing relationships with Microsoft and they don’t see enough demand for Linux on the desktop to push Linux. Some manufacturers do offer Linux as a choice in their on-line sales but they don’t go out of their way to promote it. There are a few companies that specialize in building Linux systems but it’s a niche market and their products tend to be a little pricey.
4. Users don’t want to install their own operating systems. That’s understandable. They want to buy a computer and have it work right out of the box. They’re not interested in getting inside the box and tinkering with things. I get that. I happen to enjoy installing my own operating systems. I’ve been doing it since I started messing with computers – MS-DOS, many versions of Windows, and several Linux distributions, but that’s me. Sometimes it’s been a real pain in the butt.
5. Difficult to use, high learning curve, change in work flow. These are common perceptions and there is some truth to them. Linux has gotten much easier to use over the past several years. It takes some getting used to and you’ll have to unlearn some things and learn some new things. Linux doesn’t work like Windows or Mac OS and the applications you’ll use won’t work exactly the same as what your used to. Let’s face, a lot of people don’t like to learn new things and they like to stick with what’s familiar.
6. Fear of the command line or the perception that the CLI is outmoded. I hear this a lot, even from Linux users. In many distributions, you can do almost everything you need to do from a GUI and rarely, if ever, have to use the command line or a terminal. On the other hand, the command line can be your friend and is not something to be feared. A lot can be accomplished in the terminal either form the command line or through scripts that would be cumbersome and time consuming in a GUI. Even in Windows there are tasks that are best handled in a terminal.
7. Perception that Linux users are geeks and technically inclined. This is not as true as it once was. You don’t have to be a geek or a technical person to use Linux any more. For many non-technical Linux users, it just works and it works on older hardware.
8. Lack of applications and games. That’s rapidly changing. For most tasks there is an application to do it. It probably won’t have the look and feel or do everything the corresponding Windows application does and you may have to change your work flow a bit. I’m not a gamer but more games are being ported to Linux all the time.
9. Little corporate organization and sponsorship. For the most part, Linux is the work of communities of developers and users. There are a few Linux corporate entities but nothing like the monolithic giants of Microsoft and Apple. However, major corporations are getting involved in Linux and I’m not sure that’s necessarily a good thing. Overall, Linux seems to be organic in nature and I think that too much corporate intrusion, especially by companies like Microsoft and Google, will pollute the landscape. Their influence could possibly force changes in Linux that would push out smaller players, leaving us with fewer choices and more bloat and feature creep.
10. Little effort or interest in the Linux community to make it mainstream. I heard this in a YouTube video recently and I think there’s a lot of truth to it. While many in the Linux community lament that Linux isn’t mainstream, I suspect that many of us actually prefer it that way. We are the outliers, the nonconformists, the misfits, and the mavericks. If Linux were to become mainstream we’d be just like everybody else. I fear that if Linux became as mainstream as Mac or Windows, we’d all be forced into a box with only a few surviving distributions, not much different than Mac and Windows. That is a frightening thought.

I encourage the use of Linux on the desktop and I’d like to see it more widely adopted. I want people to liberate themselves from the bondage of closed operating systems and software. But people don’t like change or learning something new, even if it leads to their liberation. To quote Thich Nhat Hanh, “People have a hard time letting go of their suffering. Out of a fear of the unknown, they prefer suffering that is familiar.”

While I would very much like to see wider adoption of Linux I don’t want it to dumbed down to the lowest common denominator with only a few standardized, pedestrian, one size fits all distributions, no different than Mac or Windows.

I use Linux because it works for me and it gives me the freedom to choose how my computers will work and to configure them to meet my needs. With Linux, my computer belongs to me and it works for me. I’m not at the mercy of some monolithic corporation who decides when my operating system and my hardware are obsolete. Linux gives me control over my computers and my computing environment.

“It’s never wrong to introduce a child to Linux.”

Feelin’ the need to code

Yesterday, I felt the need to code something so I wrote a little program to convert between Celsius and Fahrenheit. Writing functions to do the conversions was easy but it took me a while to figure out how I wanted to input the data. I thought about creating prompts within the program, maybe inside a loop for multiple conversions. What I really wanted to do was get the input from command line arguments.

With a little on-line research, I figured out how to get a number from the command line using strtol() and strtod() and using the results of those functions to determine the validity of the return value.

To get the temperature scale (Celsius or Fahrenheit) to convert from, I started off using the tests I used in FnLoC to call the help function and expanded on it to call the appropriate conversion functions. That resulted in a cumbersome set if nested if-else statements but it worked.

I took another look at the program and decided that replacing the nested if-else statements with a switch() would be better. I created a local variable to hold the command line argument and passed the first character of the string to switch(). If that character isn’t f, F, c or C, it defaults to printing an error message and calling up the help function to show the proper syntax.

It’s a rather mundane and basic program but it was a learning experience and a step forward in relearning the language.

The program has 60 lines of code with 52 lines in four functions (including main). The other eight lines are compiler directives (#include) and function declarations.

 

%d bloggers like this: