Exploding windows

I've encountered "exploding windows" on both Windows and Linux lately.  I try to resize a window and by clicking the window near the title bar, the window suddenly and unexpectedly expands to fill the entire vertical area of the monitor it inhabits.  Sometimes I'm able to do the simple resize operation which I wanted but randomly the operation results in an exploding window.  Perhaps the UI designer thought this was a neat feature but it causes me to curse each time I encounter it.  I'd love to figure out how to disable this behavior but each time I try to describe it in a Google search, I'm led down a rabbit hole of unrelated results.  It seems silly spending too much time researching something which while annoying only costs me annoyance and a few seconds to correct.

Developers need IT skills

Often software developers can benefit from having skills typically found in IT support engineers.  For example I occasionally bring small embedded systems home from work since it makes working from home more productive.  It's hard to physically reconfigure equipment I've left at the office and the reset button is tough to hit across a VPN.  

In this scenario I need to be able to access the small embedded system on our home LAN as well as my build desktop machine which stays at work.  Having a VPN client which supports split tunneling makes this possible.  It requires that there be no overlap in IP addresses between the two LANs.  It also requires that I change the static IP address on the equipment I bring home to match the subnet which my home router uses.

The diagram gives a rough idea of how the split tunneling works.

Getting paid to solve puzzles

 

The thing I enjoy most about my job developing firmware for embedded systems is that it's a lot like being paid to solve puzzles.  Many of the projects I work on are just as challenging as the old text based adventure games such as Infocom's Zork series.

The datasheets which contain information about how the chips in embedded hardware are supposed to function can be challenging to decipher.  Vendors do their best but it's not unusual for the datasheets to either be incomplete or to contain subtle inaccuracies.  A chip I developed a device driver for recently had an accurate datasheet but the device driver gave the wrong results because of an issue with the C compiler for the ARM processor.  It turns out gcc for ARM CPUs does not support signed character types by default which this chip required.  Fortunately gcc includes a compiler flag "-fsigned-char" which allows this strange behavior to be overridden.

My worst technical interview

About 38 years ago I interviewed for a software job at GEISCO (GE Information Systems).  This would be my second software position after making the switch from field engineering.  It was a systems software position, writing software to run on one of their network nodes.  At the time GEISCO supposedly ran the largest private data network in the world

One of the engineers I interviewed with felt obligated to test my software skills by asking me to write a short program on his whiteboard.   The problem was most systems software was written in assembly language at the time.  I knew 4 assembly languages which didn't overlap at all with the assembly languages he knew.  Upon learning that we didn't share a language, I asked if he still wanted me to write a program since there was no way he could determine the correctness of my program.  Being a good corporate drone, he insisted that I still needed to complete this step so he could mark it off on the interview form.  So I proceeded to write some code in GMAP, the assembly language used by Honeywell mainframes since that was the one I was most familiar with.  I guess I talked my way through it successfully because I ended up getting the job.  

My program wasn't very functional as I wrote system software and it was rare for me to need to use system calls.  I definitely had never written a system call which performed any I/O.  I believe I loaded an immediate value into a register, performed a left shift, saved it into a memory location, and then ended the program with a MME GEFINI system call which terminates the current program.

Even though I first encountered GMAP assembly language 45 years ago, I still remember the numeric value for the opcodes of a number of the instructions.  Perhaps some day I'll once again need to know that a 235 opcode is a LDA instruction (load accumulator) but I'm skeptical.  There's a lot of old knowledge I'd love to be able to purge to reclaim the memory space.

Changing the oil

I changed the oil in my commuter car today, having grown tired of the "change oil soon" messages which started appearing on the dashboard about two weeks ago.  Changing the oil is something I learned to do from helping my uncle and grandfather work on cars when I was young.  It's much quicker and somewhat cheaper to do it myself than it is to take the car to the shop since you need to include the time spent driving to the shop and waiting for the oil to be changed.

The container on the left in the picture below which now holds used motor oil always makes me think of my grandfather.  It's one of a pair of 5 gallon oil cans I have which he used for delivering heating oil during WWII.  Several times when I've taken these containers to the county recycling center to recycle the used motor oil, people have asked whether I'd consider selling them.  These cans and the other tools I inherited from him hold far too much sentimental value for me to ever consider parting with them although the idea of some yuppie paying top dollar for something like that would have made Grandad laugh.

 

I'm always pleasantly surprised to see how easy it is to access everything on this car (a Chevy Equinox).  It seems every other vehicle we've owned for the past 20 years has placed either the oil drain plug or the oil filter in an awkward spot.  Some have gone as far as hiding them above frame cross-members which makes a huge mess when the old oil drains out.  I've tried all manner of do it yourself funnels to try to coax the oil into emptying into the drain pan with varying degrees of success.

Remote Desktop replacement

At work I have 5 Linux machines (1 desktop and 4 tiny embedded machines) and a Windows laptop in my office which I need to use.  There are KVM switches which would allow to connect my monitor, keyboard, and mouse to the machines in that large a setup but they're expensive and the cabling would be a nightmare plus I'd be stuck using just one machine at a time.  I tried using Remote Desktop and VNC to access the desktop of another machine remotely but that's cumbersome and it's slow across a VPN.  To be fair, there are situations when Microsoft's Remote Desktop works wonderfully across a VPN.  At my last job I used to use the Mac version of Remote Desktop to access my Windows laptop at work.  Since a Windows machine was the destination, Remote Desktop did a great job of data compression plus it allowed the client machine to arrange windows differently than they were arranged on my Windows laptop at the office.  So my old 27" iMac which has nearly 4k resolution gave me a better viewing setup than I had at work.

Now I use X11 (aka X-Windows) for accessing all the Linux machines I need access to.  Making this work requires a couple pieces of software.

First off, I need an X Server on my Windows laptop.  That is used to display the windows created by the remote Linux machine.  I use VcXsrv, a version of the classic xorg X Server but recompiled under Visual C++.  This recompilation allows it better access to Windows resources and I find it works better than any other X Server I've tried such as xming or cygwin's xwin.  VcXsrv needs to be run on your Windows machine prior to attempting a connection to another machine.

The next thing required is an SSH client which is capable of X11 forwarding.  That allows any programs launched using the SSH client to send their displays back to the client machine.  I use PuTTY, which has been around a long time and which can handle serial and SSH connections.

Once you've run VcXsrv on your Windows machine and then used PuTTY to connect to a Linux machine (taking care to first set the configuration to allow X11 forwarding), launching a remote program and having it display on your client machine is as simple as typing the program's name.  As an example you can try xterm which will create an X11 terminal window.  Just be sure to launch it in the background by appending an ampersand so the program is placed in the background.  Otherwise, your input and output will remain tied up by the program being launched.  The command to launch xterm this way would be "xterm &".

Favorite books

Since I love to read, people sometimes ask me about my favorite books.  I inevitably leave some out so I thought I'd collect them in an easy-to-find place.  So here are my favorites.

Favorite authors still actively publishing
Connelly, Michael - Harry Bosch series
Crais, Robert - Elvis Cole/Joe Pike series
Doctorow, Cory - Little Brother, Walkaway, Makers, and others
Gaiman, Neil - American Gods and anything else
Hiaasen, Carl - anything
Ide, Joe - IQ series
Kowal, Mary Robinette - anything
Scalzi, John - anything
Sloan, Robin - Mr. Penumbra's 24-Hour Bookstore and others
Stross, Charles - the Laundry File series
Taylor, Dennis E - Bobiverse series
Wells, Martha - Murderbot series


Other favorite books (sorted by author name):
Adams, Douglas - First two Hitchhiker's Guide books and Dirk Gently series
Asimov, Isaac - Robot series, Foundation trilogy
Dudley, John Ball - In the Heat of the Night
Ellison, Harlan - Dangerous Visions and others
Feynman, Richard - Surely You're Joking, Mr. Feynman!: Adventures of a Curious Character
Follett, Ken - Eye of the Needle
Goldman, William - The Princess Bride & The Marathon Man
Heinlein, Robert A. - The Moon is a Harsh Mistress and his juvenile series
Irving, John - A Prayer for Owen Meany
Kidder, Tracy - The Soul of a New Machine
Kipling, Rudyard - Kim, Captains Courageous, and others
Leonard, Elmore - Maximum Bob
London, Jack - anything
Miller, Walter M - A Cantical for Leibowitz
Niven, Larry - Ringworld
Noah, Trevor - Born a Crime: Stories From a South African Childhood
Parker, Robert B. - early Spenser novels, Jesse Stone series, Virgil Cole/Everett Hitch series
Pullman, Philip - His Dark Materials trilogy
Robinson, Spider - Callahan's Crosstime Saloon series
Sayers, Dorothy - Lord Peter Wimsey series
Shute, Nevil - Trustee from the Toolroom
Sturgeon, Theodore - More Than Human and all others
Tolkien, J.R.R. - The Lord of the Rings trilogy
Twain, Mark - anything
Vonnegut, Kurt - Slaughterhouse Five and all others
Weir, Andy - The Martian
Winters, Ben H - The Last Policeman trilogy
Wodehouse, P.G. - Meet Mr. Mulliner and others

Favorite graphic novels (sorted by author name):
Ennis, Garth - Preacher, The Boys
Moore, Alan - Watchmen, V for Vendetta
O'Malley, Bryan Lee - Scott Pilgrim's Precious Little Life
Vaughn, Brian K. - Ex Machina

GNU Screen can make SSH sessions persistent

 I do a fair number of Linux kernel builds at work.  Doing a Yocto build for our target machine takes about an hour and 40 minutes for a the build to complete and the root filesystem to be prepared.  If I do that from home, there's a chance that I'll get a hiccup on my VPN connection which might disrupt the build in progress.  Even at work, I ssh into my Linux build machine from a Windows laptop and use xterm sessions for most of my development tasks.  If I kick off a build before heading home, there's always a chance that Windows will decide to do an update which could also disrupt my build.

Fortunately GNU Screen can make your sessions persistent through disruptions due to network disconnections or other reasons.  Now I make sure to start a GNU Screen session before doing my build.  I start named screen sessions with a command such as "screen -S build".  That way, if my session is disconnected, I can rejoin it with the command "screen -r build".

The one thing I don't like about GNU Screen is its default escape key, Control-A, since that interferes with the default Emacs command line editing mode in Bash.  So I've created a ~/.screenrc configuration file with the following command to change the escape key to Control-T.

escape ^tt

Running Ubuntu Linux in a VirtualBox VM

I've recently started a new job which requires me to build software under Ubuntu Linux.  Since I don't particularly care for the Ubuntu distribution and having only a single development PC which runs Windows 10, the natural solution is to create a VirtualBox virtual machine and install Ubuntu in that.  However the combination of VirtualBox and Ubuntu caused a few problems for me.

The first problem I encountered is that VirtualBox seems determined that new VMs will all run at very low resolutions.  I've seen 640x480 being used on when running VirtualBox on both Macs and PCs running Windows 10 and it's ridiculous to be stuck with a resolution that first appeared in 1987.  At that resolution, it's difficult to get through the Ubuntu installation setup as some of the buttons appear off the screen.  That issue I believe is Ubuntu's fault.  They should make it possible to see all buttons regardless of screen resolution.  Poking around on Google, I discovered that there's a command line utility included with VirtualBox which allows you to run higher resolutions in the guest OS in VMs.  First make sure that VirtualBox is not running.  Start a command prompt with administrative privileges and navigate to the directory where VirtualBox is installed since the utility we need is not located in the command path.  The directory you want will most likely be something like "C:\Program Files\Oracle\VirtualBox".  Issue the command "VBoxManage setextradata global GUI/MaxGuestResolution any".  This plus installed the Guest Additions tools in the guest OS should allow you to change your VM to a higher resolution.

The second problem I encountered was after I installed the GUI version of my favorite editor, Vim, using the command "sudo apt install vim-gnome".  I was able to launch gvim but the menu was hidden which makes accessing a few features more difficult than necessary.  It turns out Gnome on Ubuntu has a bug which prevents some applications from displaying a menu bar.  The workaround is to define a command alias to launch Vim which undefines the UBUNTU_MENUPROXY variable.

Vi/Vim macros

Of all the editors I've used (and there have been a lot) I like Vi/Vim the most.  Once you get past the very steep learning curve, you can become extremely productive, in part because you almost never need the mouse.  I've been using Vi on and off since 1990 which has imprinted the commands into my fingers so I no longer think about them.  A few of the macros below have existed in some form since that time.

The macro commands below are from the _vimrc file I use to customize Vim under Cygwin running on Windows 10.  Note that characters in red below indicate control characters.  ^M is control-M which is the code produced by the Enter key on Windows keyboards.  ^[ is the code produced by the Escape key.

One of the things which saves time for me is having the ability to easily copy and paste lines from one file being edited to another.  These macros help me accomplish that.

" set temporary yank and paste filename
let @p="c:\\Users\\ViUser\\Documents\\vim\\vim.tmp"

" mark beginning of a line block (uses the a mark)
map \m ma

" yank lines to temp file (from mark to cursor pos. - uses b mark, b buffer)

map \Y :'a,.w! p^Mmb"ay'a`b

" paste lines previously yanked or deleted to temp file at cursor pos.

map \P k:r p^M

Another thing I do frequently is edit log files and search for my initials which I include in any log messages I add.  The macro below searches the log file being edited for the letters "TBD" and removes all other text.  Just remember to quit without saving or use the Vim undo command.

map \gt ^[ggVG!grep TBD^M

Customizing the bash prompt

I prefer to use a bash prompt which displays both the date and time.  That makes it easier to see when commands were issued when scrolling back through the terminal's buffer.  Here's what my prompt looks like.

The bash settings for this prompt are shown below.  You can add these lines to your .bashrc file.  For operating systems which support an admin or root user, I change the prompt's background from blue to red to give quick confirmation of that elevated privilege level.

# Attribute codes:
# 00=none 01=bold 04=underscore 05=blink 07=reverse 08=concealed
# Text color codes:
# 30=black 31=red 32=green 33=yellow 34=blue 35=magenta 36=cyan 37=white
# Background color codes:
# 40=black 41=red 42=green 43=yellow 44=blue 45=magenta 46=cyan 47=white
PBG=44
PFG=37
TFG=36

PS1='\n\[\e]1;Term ${$} \a\e]2;\u@\h - ${PWD}\a\e[1;${PFG};${PBG}m\][\D{%m-%d} \t] eh? \[\e[m\] '

Searching for source files which contain multiple keywords

Recently I was presented with the challenge of searching for the code which built a SQL query.  I knew what the query looked like from a log file but searching for individual terms used in the query such as SELECT, FROM, or WHERE produced hundreds of matches which I didn't want to waste time checking one at a time.

So I created the following bash script to search files for each term in order.  I used ack instead of grep for the first search so it would pick only source files of interest for me.  The results from my bash script returned only a single file which contained all the terms and it was this one which I needed to modify.

if [ -z "$2" ]                       # Is parameter #1 zero length?
then
    echo "usage -- rgt term1 term2 [term3]..."
    exit 1
fi

files=`ack -l "$1"`

# shift past the first search term argument since 
# we've already used that one 
shift  

for var in "$@"
do
    files=`echo $files | xargs grep -l $var`
done

if [ -z "$files" ]; then    # are results zero length?
    echo "no matching files found"
else
    echo "matching files:"
    echo "-------------------------------------"
    echo "$files"
fi

Quick and easy code searches

Getting presented with a large and unfamiliar code base can sometimes prove daunting.  One of the biggest challenges is how to efficiently search for things when you need to make changes.

Since I'm a big fan of platform independent tools, I had been using recursive grep searches but those frequently return too many results.  It can be difficult to limit the files searched to just the source files of interest.  Perhaps you have a unit test directory you don't wish to search.  You might also want to skip directories containing library files or other binaries.  I prefer a tool called ack to help limit the unwanted files being searched.  That prevents lots of false positives which you need to wade through.

Creating a file called .ackrc in your home directory is an easy way of setting the default settings for ack.  The following sample .ackrc file configures ack to ignore a few directories which normally don't contain code of interest.  It also sets an alternate file extension for makefiles and configures the default source languages of interest.

--ignore-dir=.svn
--ignore-dir=dist
--ignore-dir=docs
--ignore-dir=examples
--ignore-dir=lib
--ignore-dir=tests
--type-add=make:ext:make
--asm
--cc
--make

Using ack and an appropriately configured .ackrc file can significantly reduce the number of lines of matches you must check when searching your source tree for a keyword.

Making code searches easier

When modifying source code I'm not familiar with, it's usually necessary to do some recursive searches to figure out what to change.  You can use a simple recursive grep but I prefer a tool called ack.  You can download ack in one of several forms.  I prefer the all-in-one perl script version.  I prefer ack because it can be configured via .rc (run command) file or command line to limit the searches to files of interest.  You can ignore files with certain extensions or entire directories.  Few things are more disheartening than searching for a term within the code only to find out it appears on many hundreds of lines.  Who feels like wading through hundreds of lines to find what you're actually looking for?
 
I also use the following bash function to pipe ack's output to gvim so I can weed out unwanted matches quickly.  This is handy if the search term is a common word which is also used as a variable or function name.  I delete lines containing any variations which aren't of interest which helps reduce the job to something more manageable.

The ack script may be replaced with a simple recursive grep if you'd like.  You can also use a different editor if you don't care for Vim/Gvim.  You'll just need an editor capable of accepting input from stdin.  The following function also tells gvim to highlight the search term which I find to be a time saver.

function    ackvr    # invoke ack perl script and edits the match
{
    if [ -z "$1" ]; then
        echo "Usage -- ackvr SearchPattern
    else
        echo "ack searching for $1"
        ack "$1" | gvim -c "/$1" -
    fi
}

Using RSS feeds to save time

I've long been a fan of RSS feeds as a way to save time when monitoring blogs.  It affords me the ability to see the headlines of new posts (and only the new posts) as they appear.  I can choose to visit the blog if the headline sounds interesting or if none of the articles catches my eye, I can mark all headlines read which makes the web site disappear in my RSS reader until the next time they add content.  It is so much faster than actually visiting a bunch of web sites that it's not funny.

I have three separate lists of RSS feeds I monitor.  I use a cross-platform app called QuiteRSS on both my Mac at home and on my Windows laptop at work.  On my phone and tablet device, I use a mobile app called Feedly to monitor a third set of RSS feeds.

At home I follow RSS feeds for beer news, book releases, and information about RetroComputing.  I don't read about these topics at work because I don't feel right about asking a company to pay me to do that.

At work I follow a number of technical RSS feeds on computer security, software development, embedded system, computer communications, and a few other tech topics.  These are all directly or indirectly related to my job.  Having these RSS feeds to read allows me to take small breaks at work while my software is building or when I'm waiting for code to download to one of my development boxes.  I'm a firm believe in the studies that say these micro-breaks improve productivity.

Whenever I have a bit of downtime during the day such as while waiting at an appointment or in line at a store, I can look at the local news sites I monitor in the Feedly app on my phone.  Feedly synchronizes feeds so when I look at those same feeds at home on my tablet device, I only see articles I haven't marked read on either device.

Preventing strange colors for the "ls" command

I occasionally need to connect to a Linux server via ssh.  Since I use an ssh client which has a dark background, the default colors used by the ls command frequently makes directory listings difficult to read.  Fortunately you can solve this one of two ways.


For a solution which will persist throughout the ssh session, you can issue the "unalias ls" command.  That removes the alias which causes the odd coloration.  It will reappear the next time you log into that server.


For a non-persistent solution you can preface the ls command with a backslash.  Using "\ls" prevents any command alias from being used.

Using Vim's folding feature to hide inactive conditional code

I was recently looking at some C code which had lots of conditionally compiled sections (#if, #else, #endif).  I don't care for code like that but sometimes it's a necessity when source code must support multiple hardware platforms.  In any case, it makes the code harder to read.  So I've whipped up a little macro which if placed on the #if or #else line, will use Vim's folding feature to hide that portion of code.


map    \fc   mx^%:'x,. fold


To unhide the folded section, you can issue the zd command.  I've buried that in a macro invoked by "\fd" since the more mnemonic macros are easier for me to remember.

Gaining productivity with smartphones

I'm often surprised at how many people load their smartphones up with time wasters like games.  There were a few problem solving desktop games which appealed to me years ago but first person shooters and the mindlessly repetitive games I've seen on phones don't hold any interest for me.  Instead I've got my iPhone loaded with apps which increase my productivity and I thought others might find an idea or two in this list which might help them as well.

Cloud Storage (DropBox) - My storage needs are modest so the free account suffices for me.  This is the easiest method for sharing files between multiple desktop/laptop computers and tablets/phones.  I don't keep any sensitive data on here long term.  For times when I need to temporarily transfer such data, I create a TrueCrypt volume to store such data and transfer that up to DropBox.

Database (Bento) - Sadly, this handy little flat-file database program has been discontinued.  I use it to store all sorts of information such as books I want to read and/or purchase, books that I own (to prevent duplicate purchases in paper form), house maintenance tasks, car maintenance done, etc.  Since Microsoft has made Excel freely available, people who want similar capabilities might choose to use it instead.  It has most of the capabilities of a simple database like sorting by different fields.  If you combine it with Dropbox, you can even access your data from either your phone or a desktop PC.

Text Editor (DropText) - This gives me the ability to create and edit text files which can be shared with a desktop or laptop PC when combined with DropBox.  It allows me to maintain a paperless existence at work.  Staying paperless allows easier searching of notes.  Making notes isn't useful if you can't easily find specific data within them.

Password Manager (1Password) - Between work and home, I have around 600 unique username/password combinations to keep track of.  1Password allows me to do this gracefully while storing them securely.  I choose the WiFi Sync option so my password data isn't accessible on the cloud because I don't trust any company's cloud security.

Web Content read later app (Instapaper) - Occasionally I'll find something in a browser or one of my smartphone apps which I'd like to read later when I'll have less distractions.  Instapaper lets me store these URLs to read later.  It's available as a bookmarklet which works in all browsers.  It also works in some of my smartphone apps.

Library e-book/e-audiobook borrowing (Overdrive) - I use it mostly for borrowing e-audiobooks from our county's library system.  It keeps my 40-70 minute commute (each way) from getting boring.  Buying this many audibooks would get quite expensive in a hurry.

Podcast app (Overcast) - This makes keeping up with podcasts painless.  I've not found another podcast app which works nearly so well.

e-book reader (Kindle app) - Often I find myself unexpectedly stuck waiting somewhere like a dealer service department or a doctor's office where my choices of entertainment are old People magazines or whatever inane channel they have the TV tuned to.  Instead I opt to read whatever Kindle book is currently occupying me at home.  Since the Kindle app automatically syncs between devices, I don't even have to remember which page number was the last one I read.

PDF/ePub document reader (iBooks) - For the last 5 years or so, I've been buying all my technical books from O'Reilly in ePub format.  That allows me to have them with me on my phone in case I need to look something up quickly.  Searching is always better than trying to use the index in a paper book.  Plus I have access to my tech books both at work and at home without having to lug them home in my backpack each night.

RSS reader (Feedly app) - I keep up with tech blogs via RSS.  It lets me know when new articles are published and a glance at the title lets me know whether I'm interested enough to spend the time reading them.

Dynamic e-magazine (Zite or Flipboard) - Reading a fixed set of blogs sometimes lets interesting items sneak past me.  Zite allows me to tailor the type of information I'm interested in reading.  There's just enough serendipity in their matching that I'm usually amused or entertained by a few articles it finds for me.

So that's my list of the smartphone apps I use most often.  Are there any I've missed which you like?

USB hubs

Many years ago while working for U.S. Robotics, I developed USB device drivers for a living and learned a fair amount about USB.  The big takeaway from that experience is I'm disappointed that Firewire didn't win the external bus contest.  It's a much better designed bus.

One of the necessities for using USB is a hub since few computers include enough USB ports for anything other than the least demanding user.  Since this is the case, it pays to understand a bit about USB hubs since you'll probably need one.

First off, there are multiple flavors of USB - 1.x, 2x, and the recent 3.X.  The key difference as far as users are concerned is the speed.  So the first concern would be to purchase a USB hub which supports the port on your computer.  Unless you've got a fairly recent computer, chances are you've got the USB 2.x flavor.  There is some degree of backwards compatibility so you could theoretically get a USB 1.1 hub but USB 1.x was so slow it's not useful for connecting anything except a mouse or keyboard.

The tricky part comes in choosing which type of power you want your hub to have.  Like most things in USB, there are multiple choices.  You can get a bus powered hub which will derive all its power from the port it's connected to or you can choose a self powered hub which needs an external power supply (AKA wall wart) to power it.  If you don't read any further, take this bit of advice - Never choose a bus powered hub!  To explain why, we'll need a little background about how USB distributes power.

The USB 2.x standard states that USB hubs (and even the ports on the back of your computer are connected to a hub) have to supply 5 volts and up to 500 milliamps (Ma) to each port.  Most likely the ports on the back of your computer offer the full 500 Ma (although a few forward thinking manufacturers offer higher current for those devices which require it).  Worst case if you plug your newly purchased USB bus powered hub with 4 ports into a port on your computer, that new hub will only have 500 Ma to power itself as well as to distribute to its 4 "downstream" ports.  A rule of thumb is that the hub itself takes 100 Ma leaving only 100 Ma for each of its 4 ports.  If you're not familiar with current ratings of devices, 100 Ma isn't a lot.  There are some USB thumbdrives which require more than 100 Ma to function.  So a bus powered hub isn't much good for devices other than a mouse or keyboard or perhaps a low powered USB thumbdrive.

That makes a pretty strong case for choosing a self powered USB hub.  This can also be trickier than it sounds.  Those wall warts aren't always adequate on cheaper USB hubs.  I've seen 8 port USB hubs with a 1000 Ma power supply.  That doesn't leave the user much better off than using a bus powered hub.  So the rule of thumb here is look for a self powered USB hub with a minimum of 500 Ma per port which means an 8 port hub would require 4000 Ma or a 4 amp power supply.

You don't need to buy the most expensive USB hub but it can save time, money, and headaches in the long run if you choose something better than the least expensive.

Command line editing

A great many tools (including the Unix/Linux login) use a standard "readline" library which by default uses many key bindings from the Emacs editor.  It's also possible to configure readline to use Vi editor bindings.  While I'm not an Emacs user, I find it much easier to use the default bindings and to memorize a small subset of those shortcuts.  That way you don't have to worry about whether the program taking your input recognizes that you prefer Vi commands.  The login process won't know that since you are stuck using system default settings prior to logging in.

The following list shows the readline shortcuts I find most useful.  There are more of these available but many deal with situations I don't find useful very often so they're not worth memorizing for me.  If you're interested, you can easily find the rest by typing "Unix readline shortcuts" into Google.  In the following list, the "Ctrl-a" means to hold the control key down while also typing the "a" key.

• Ctrl-a – go to the start of the command line
• Ctrl-e – go to the end of the command line
• Ctrl-k – delete from cursor to the end of the command line
• Ctrl-u – delete from cursor to the start of the command line
• Ctrl-l – clear the screen
• Alt-b – move backward on the command line by one word
• Alt-f – move forward on the command line by one word

I can't tell you how often I use the Ctrl-u shortcut when typing a long password during a Unix/Linux login.  There's something about not being able to see how far along you've gotten in the password entry which makes it easy to forget what's next.

Now we can combine this readline editing with the Bash command history.  You can use the up arrow to recall previously issued commands and then use these handy readline shortcuts to edit one of the commands and issue the modified command.  Sometimes that can make for a significant time savings.

Command aliases using grep

I keep quite a few command aliases and environment variables which speeds up my use of the command line.  However sometimes it can be difficult to recall exactly what I've called one of the ones I haven't used in a while.  To help with this problem, I find it handy to define a few easy to remember command aliases to help me search my list of command aliases, environment variables, and recent command history.

alias   ag='alias | grep -i'
alias   eg='env | grep -i'
alias   hg='history | grep -i'





The need to search through command aliases and history are probably somewhat obvious.  You may ask why I find the need to keep so many environment variables though.  It turns out they're incredibly handy as shortcuts for frequently used directory paths.

For example, I always keep a shortcut called $DT for my Desktop.  That makes it very easy to move or copy a file to the Desktop using a short command like "cp filename $DT".  It removes the need for me to remember the Desktop path on all the OSes I use on a regular basis (Windows, Linux, and Mac OS X).

That may seem a simplistic use but I also keep environment shortcuts for the paths to all the SDKs (software development kits) and virtual machine shared directories I use.  That frees me up to remember more important things.

Changing your shell prompt

I find it useful to use a colorful prompt on all the Unix or Unix-like machines I have accounts on.  It makes it much easier to scroll back to find the start of output of previously issued commands.  Otherwise you're wading through a sea of similarly colored text trying to find something which looks like your shell prompt.  That may not seem difficult but when you're dealing with makefiles which can output hundreds of lines of output, you need all the help you can get.

Look at the prompt in the following snippet from my terminal window.  It's very obvious where the prompt is and the date and time stamp in the prompt prove useful quite often.  Note that it's the date and time stamp of the prompt which follows the command output which provides an approximate time of command execution.

Another thing I like to do is to color code my prompts with the level of privileges associated with the account.  Admin accounts get a red background while user level accounts get a nice soothing blue.  You can never have too many reminders of the fact that you're using an admin account.

There are a couple ways to create a prompt like this.  The easiest is to use a handy web site like the .bashrc generator to help you configure your prompt.

I prefer having greater control over my prompt than most tools like the bashrc generator provide and I find too much information in a prompt distracting.  So the following snippet from my .bashrc file does the trick nicely.  You may need this ANSI escape sequence reference to figure out what my prompt is doing.  There are two main parts.  First I'm overriding the text in the terminal window's title bar with "Rods Terminal" followed by the working directory.  Then we jump back into the actual window, change foreground and background colors, and print our prompt.  Finally, we change back to some subdued colors for normal command output.

# Attribute codes:
# 00=none 01=bold 04=underscore 05=blink 07=reverse 08=concealed
# Text color codes:
# 30=black 31=red 32=green 33=yellow 34=blue 35=magenta 36=cyan 37=white
# Background color codes:
# 40=black 41=red 42=green 43=yellow 44=blue 45=magenta 46=cyan 47=white
PBG=44
PFG=37
TFG=36

PS1='\n\[\e]1;Term ${$} \a\e]2;Rods Terminal ${PWD}\a\
\e[1;${PFG};${PBG}m\]\
[\D{%m-%d} \t] eh? \[\e[m\] \n'

Making code reviews easier

Our source trees at work contain quite a few files spread out over many directories.  So reviewing code changes done by other engineers used to present a challenge.  Being handed 10 files to review used to mean manually finding each in the source tree so I could set up my diff tool with the appropriate paths to see what changes had been made to each file.  So I came up with a small bash script to automate the finding of base source files for comparison.

When I receive an e-mail containing source files to review, I copy all the modified source files to a directory called /c/review/new (this directory looks odd because I'm stuck on a Windows machine and run Cygwin to make it easier to use).  Then I cd to the top of a source tree with no changes I keep synched up with our SVN server and I type the name of my script below.  I call it "revcp" for review copy.  It finds and copies files from the current directory into a directory called /c/review/old.  Once that's done, I fire up WinMerge pointing at the old and new directories.

The only thing which can present a problem is that sometimes there are files for review for which there are multiple matches.  Makefiles are a prime example since we have quite a few of them.  The script will find all matches and prompt the user for which file to copy.

Is it perfect?  Not by any stretch of the imagination.  But for a "quick and dirty" tool which only took 15 or 20 minutes to write, it saves me quite a bit of time.  Now I no longer dread the arrival of code review requests.

#!/bin/bash
#
#   revcp (review copy)
#
# Description:
#   Given a single directory containing a group of source files to be
#   reviewed, this script will find matching files from the source tree
#   starting at the current directory for comparison.
#
# One time preparation:
#   1)  Modify NEW_DIR and OLD_DIR environment variables below to specify
#       the directory where you've placed the files to be reviewed and
#       the directory where you'd like the corresponding base files
#       to be copied.
#
# To use:
#   1)  Copy all files to be reviewed into the directory pointed to by the
#       environment variable NEW_DIR set below
#   2)  cd to a directory in your source tree above all files being reviewed
#       such as /c/svnBase/riot/client (where svnBase is the directory where
#       your svn source tree is checked out).
#   3)  Run this shell script under Cygwin or another Unix shell.
#   4)  If duplicate files are found by script the user will be prompted to
#       choose the desired file.  Once chosen, the script will manually copy
#       the selected file to OLD_DIR.
#   5)  Use WinMerge or another diff utility which can diff entire directories
#       to compare the contents of OLD_DIR with NEW_DIR
#

# This directory contains new files to review
NEW_DIR=/c/review/new

# Files found from current path will be copied to this directory
OLD_DIR=/c/review/old

FILES=$NEW_DIR/*

function FindMatchingFile
{
    CurFileName=`basename "$1"`
    NumFiles=`find . -name $CurFileName -print | wc -l`
    if [ $NumFiles -eq 1 ]; then
        echo "Copying $CurFileName"
        find . -name $CurFileName -exec cp {} $OLD_DIR \;
    elif [ $NumFiles -eq 0 ]; then
        echo "File $CurFileName not found... must be new file"
    else
        echo ""
        echo "Found multiple matches for file: $CurFileName"
        echo ""
        MatchingFiles=`find . -name $CurFileName -print`
        i=1
        for m in $MatchingFiles
        do
            echo "$i - $m"
            let "i=i+1"
        done
        echo ""
        echo -n "Enter number of the file to copy or 0 to skip: "
        read FileNum
        if [ $FileNum -eq 0 ]; then
            echo "Skipping $CurFileName"
        elif [ $FileNum -le $NumFiles ]; then
            i=1
            for m in $MatchingFiles
            do
                if [ $i -eq $FileNum ]; then
                    echo "Copying file #$i - $m"
                    cp $m $OLD_DIR
                fi
                let "i=i+1"
            done
        else
            echo "User input too large"
        fi
        echo ""
    fi
}

echo "revcp - copy files for review"
for f in $FILES
do
    FileNameToFind=`basename "$f"`
    FindMatchingFile $FileNameToFind
done

Changing to a sibling directory easily

I deal with multiple source trees on a daily basis.  Occasionally it's handy to switch from a subdirectory in one to the same subdirectory in a different source tree.  So I put together the following set of shell functions (similar to command aliases but they allow greater flexibility in checking parameters) to make this easier.

For example, let's suppose my current directory is ~/src/tree1/subdir1/subdir2/subdir3/ and I want to switch to the same path in the directory ~/src/tree2.  With these bash functions defined, I can type the command "cds tree1 tree2".  If I want to return to the previous directory, I can hit the up arrow key to recall the command, cursor over, and change the "cds" command to "cdsb".

# cd sideways (replaces one portion of current path with new string and changes to that directory)

function    cds

{

    if [ -z "$2" ]                           # Is parameter #1 zero length?

    then

        echo "Usage: cds DirPatternToReplace DirNewPattern"

    else

        NWD=`echo $PWD | sed -e "s/$1/$2/"`

        echo "Changing directory"

        echo "from: $PWD"

        echo "to:   $NWD"

        cd $NWD

    fi

}

# cd sideways back (same as previous command but parameters are reversed to go backwards)

function    cdsb

{

    if [ -z "$2" ]                           # Is parameter #1 zero length?

    then

        echo "Usage: cdsb DirPatternToReplace DirNewPattern"

    else

        NWD=`echo $PWD | sed -e "s/$2/$1/"`

        echo "Changing directory"

        echo "from: $PWD"

        echo "to:   $NWD"

        cd $NWD

    fi

}

Bash history

I've always had a strong preference for using command lines interfaces (AKA CLIs) over GUIs.  I can get tasks accomplished much faster using a Unix bash shell than I can on any GUI.  Plus CLIs lend themselves to greater levels of customization than GUIs do.  If I can customize a user interface, I can adapt it to the way I prefer doing things which makes the CLI even faster to use.

One of the customizations I use in Unix style shell interfaces is to modify how commands are stored in the shell command history.  I prefer the Bash shell (AKA Bourne Again Shell).  If you don't understand the humor in that, a little time on Google can clear it up for you.

The first step I took is to specify a permanent file for my shell history.  This allows multiple shells to share the same command history which frees me from the need to remember which shell I entered a command of interest into so I can recall it.  The following lines in a .bashrc file will set this for me.

# override default history size and file settings
export HISTSIZE=10000
export HISTFILESIZE=20000
export HISTFILE=~/.bash_history

I also need to prevent my history from being wiped out when a shell is closed.

# prevent closing a shell from overwriting history (append instead)
shopt -s histappend

I also find it helpful to store timestamps for each command stored in the history.  This can be useful for shared computers where you may not be the only user entering commands.

# Store timestamp information for each command
export HISTTIMEFORMAT="%m%d %T  "

I also hate seeing duplicate commands in my command history.  One of each is sufficient and any more than that just clutter up the history unnecessarily.

# don't store duplicate commands
export HISTCONTROL=ignoredups:erasedups

And last but not least, I hate to waste space in my command history for short commands.  Typing ls is faster than looking it up in the command history so why waste space that could be storing more complicated commands that are harder to remember?

# ignore certain commonly issued commands
export HISTIGNORE="env;exit;history;ls:ps:pwd"


These lines added to your .bashrc should work on Linux, Cygwin under Windows, or Mac OS X terminal sessions.