BASHing Visual Basic Out of the Picture

June 28th, 2010 by Jacob Barkdull

Awhile ago, two family members of mine were programming something for a simple task, they chose to do it in Visual Basic as the program was going to be running in a Windows environment anyway. The task was having a simple program that would run in the background -- or ran when needed -- to print a specific file (or multiple files) whenever the file(s) changed, specifically, whenever the file was modified. This was being done on a Windows system so file changes related to permissions, ownership, etc, didn't apply.

There were small problems getting it to work properly (as this can happen programming anything.) Seeing the code, everything looked like it would work, but it didn't, not ever having much experience with Visual Basic -- I only learned a few things, and they were during my last year using Windows, this was around three years ago -- I could only offer a few guesses related to the errors it was throwing. The code reminded me of Python, and the errors reminded me of C++, C#, and Perl mixed together, they were not at all useful.

When they first started working on it, I had already mentally written the code to accomplish such a task in my head as PHP, but I wasn't quite sure how I would run the PHP code in the background locally on a Windows system, let alone print to a local Windows printer using PHP.

That's when it hit me, BASH!

No, nothing bashed me in the head, I am referring to GNU BASH. I knew that it would be an easy task in BASH, a couple variables, a simple "while loop", an "if", and the print command "lpr". Here's what I got:

#!/bin/bash

moddate=$(stat -c %y workdoc.txt)
moddate=${moddate% *}

while [ 1 ]; do
    sleep 1
    newmoddate=$(stat -c %y workdoc.txt)
    newmoddate=${newmoddate% *}
    if [[ $newmoddate != $moddate ]]; then
        lpr workdoc.txt
        moddate=$newmoddate
    fi
done

What I noticed was: this is near 50% smaller than Visual Basic's source. And BASH automatically runs in the background of a graphical environment -- unless it's executed from an open graphical terminal (such as gnome-terminal) -- at least in GNOME it works this way.

I'll note that I didn't find a way to use it conveniently on Windows, but it would be easy enough to run the code through SHC and compile the C source code for Windows. Despite the title, I eventually helped finish the program with a simple BATCH script, so both BASH and Visual Basic were out of the picture.

I write about this because I find it interesting, and because it's been a long time since I've written any code that someone might have a real-world or business related use for. So... It's simple! It's fast! Use it if you want :)

On the Blog RSS

May 9th, 2021

GNOME 40 is finally out and I'm happy to say a small contribution of mine made it into the release. My contribution adds a new feature to GNOME System Monitor version 40. Few articles about GNOME 40 mention it, but some power users might find my contribution useful.

November 15th, 2019
If you leave this option checked when you export your image, any pixels you erased will be saved in the exported image. They will not be truly erased, just made fully transparent. In other words, the data that describes the color of each pixel will be preserved, they will just be made invisible. This option has privacy implications. With it enabled, what you erase from an image may still be present in transparent pixels.
May 2nd, 2015

Over the past few days I've been in talks with a nice fellow named Kamil Jablonski, a concept artist, graphic designer, and web developer who recently contributed a Polish locale for HashOver. He shared with me a logo design for HashOver, that after some back and forth became, in my opinion, a very cool design.

Subscribe to Newsletter

Want to get the latest news and updates about my software, blog posts and behind the scenes information? Than subscribe to my newsletter to stay up-to-date!