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.