One script with different script names.

Sometimes I want to have my bash script behave differently based on how I call it without having to set up different parameter inputs. For example, I might have a script that can sync a file from a local server to one of two remote servers. I can make my script to take in parameters so I can call it using 'syncfiles -h serverA; syncfiles -h serverB', but sometimes I forget what my params are and it's easier to remember 'syncToA' or 'syncToB'.

To do this is pretty simple, yet I always have to look it up each time so I'm writing this as note to myself.

#!/bin/sh

echo $0

if echo $0 | grep "syncToA" > /dev/null
then
   # do stuff
elif echo$0 | grep "syncToB" > /dev/null
then
   # do stuff
fi

Next, create symlinks to the original source files with the names you chose (i.e. 'symlink syncToA syncfiles').

GNU Screen and Bash

As pretty as GUIs are, sometimes it is most efficient to work in a text console which is why I find myself using GNU Screen. However, Screen's command starts with CTRL-A which is also Bash's move to start of line command. To have it work, use 'ctrl-a a'.

Also, screen sets the value of TERM to be screen so if you have any settings based on the TERM value, update it appropriately.

One thing about using screen is that you lose your terminal's scroll buffer so as line scroll past your view you can't just use the scrollbar to move up to see what you missed. Instead, screen has it's own scroll buffer that you can use. You can set the buffer size using 'defscrollback #' (where # is the number of lines) in your .screenrc or in the screen command line (ctrl-a). You can switch to the buffer with 'ctrl-a [' (and exit buffer mode with ESC). Navigation follows normal VI keys.

Finally, I noticed that hitting the delete key didn't send backspace as expected with using the OSX terminal. To correct that, add the following to your .screenrc:

termcapinfo xterm-color kD=\E[3~

This tip came from here.

How Bad Are the Chicago Bears?

The only thing that Bears fan can look forward to is for the Bears to continue to be humiliated so badly that the coaching staff and team management are forced to face reality and start making some changes. It's pretty sickening to hear them talk when they are 4-6 about how they're still in post-season chase. Give the fans some credit! I love the Bears and I cheer for them even when they lose, but please show some effort! Every week, it team looks dejected and seems like they are just trying to get home. It would be nice to see some emotion and passion from somebody. As you listen to the broadcaster in each game, they language they use to describe the team is the language used about a rebuilding team. Essentially, they've stopped talking about the current team and can only find positive things to say on which young players have the POTENTIAL to some day be a good player.

The Bears were so bad that on a nationally televised game Fox actually switched away to another game because the Bears played so badly. Nearly every week a team play the Bears and come away with some sort of record. Last week it seems like it was the first time in a long time that I saw the Bears have the lead even if it was short lived. Against the Vikings, Minnesota scored on 8 of 9 possessions. They are not even competitive anymore.

My VIM cheatsheet

To help me learn VIM keys, I put together a cheat sheet which I load onto my desktop much like how I handle my calendar/todo.

I'm not sure how much this cheat sheet will help others because I left out the commands that I already know well and left the commands that I'm currently learning. I expect that I'll update the list as I get more familiar with VIM.

----  BUFFER  ----
:e          set buffer
:b          goto buffer (next|prev)
:sp         new window/file above
:vs         new window left
:q          close current window
:qa         quit all windows
ctrl-w      move to window
ctrl+w =    autosize window
:ls         list buffer
:bd         buffer delete
:sav        save-as
u           undo
ctrl-r      redo
.           repeat
ESC         ctrl-[

---- NAVIGATION -----
gg          goto start of file
G           goto end of file
:54         goto line
80|         goto column
ctrl-g      show file info
ctrl-e      scroll up
ctrl-y      scoll down
ctrl-b      page up
ctrl-f      page down
zt          scoll line to top
w           next word (ctrl+right)
b           previous word (ctrl+left)
zi          toggle folding

---- SELECTION ----
v           visual select
shft-v      line select
ctrl-v      column select
y           copy selection
p           paste selection
=           reindent 
>           indent
<           unindent
:set list!  toggle visible whitespace
xp          transpose
r           replace
s           substitue
x           delete char

Trying to switch to VIM.

I've always been an EMACS user on UNIX and it sometimes seems like it can do EVERYTHING. The one problem with EMACS is that a lot of production systems (and even many non-prod) won't install it which means that when I'd have to use vi/vim and I'm just not as fluent with it. Especially since when I'm on those systems means that I'm trying to do fast debugging and navigation, being slowed down by my lack of experience with the editor is really frustrating.

I've decided to try to switch to VI/VIM to be the primary editor for awhile to force me to learn. There is no need to tell me that EMACS kicks butt (I agree), but unless you can get emacs installed everywhere, this is really more a decision based on my current situation.

Being Thankful

With all that has been going around, I'm very thankful of having my family and the friends who have helped us get through everything.

Happy Thanksgiving, Everyone!

Nice font for terminal and code editing

Terminus is a very nice looking font that is well suited for programming editors and terminals.



It is an open source font and many linux distributions have it available. I haven't tried any for OSX, but you can compile for xterm on OSX/X11 from macports.

Pretty printing source code

Sometimes it is just more comfortable reading source code on paper, but printing directly from a text editor often gives an output that is ugly and wasteful. Just try opening up your source code in notepad, textmate, etc. and print. It might look very nice on your screen but on paper the fonts are big with lots of white space.

Printing source code is a different beast then printing narrative text and has some special requirements. The first is to include line numbers for easier reference. Different languages have different formatting and sometimes you want to print with color syntax to help find what you're looking for. It can also be helpful to print two pages on one sheet so you can see more of the code and reduce paper waste.

On Windows/DOS, programmer editors usually have features for handling these types of pretty source code printing. Strangely, none of the editors I've seen on OSX have it (TextMate, Eclipse, Smultron, etc.) and since I've been dealing with code more I wanted a solution.

Fortunately, OSX's UNIX underpinning allows me to use the classic enscript tool to handle this.

 enscript -2 -q -C -Ec --color -f Courier8 -r -p OUTPUTFILE SOURCEFILE

This generates a Postscript file (default), with 2 columns (2), quiet mode (-q), line numbers (-C) , using C syntax (-Ec), in color with Courier 8 pt font (-f), in landscape mode (-r) to a file called OUTPUTFILE (-p) from SOURCEFILE.

You can find different language syntax available for the -E option with "enscript --help-highlight" and you can set different output formats besides PostScript with the -W option (i.e. html).

"-p -" will tell enscript to print to stdout so you can pipe it to lpr.

Fedora install needs to be quicker.

Upgrading my system from Fedora 8 to something more recent has been on my todo list for awhile and last night I finally took the plunge. I had already downloaded iso images for Fedora 10 and 11 so I was ready to do the install from the DVDs. I couldn't go straight from 8 to 11 because there has been some significant changes in the distribution so I had to first upgrade to 10 first.

The upgrade to 10 was pretty smooth but as with my previous experience, I had to manually clean up some dependency issues before I can do the first 'yum update'. I expected the upgrade from 10 to 11 to be smooth but I actually ran into more issues. Firstly, there was some problems on the first reboot where Fedora couldn't start X. It didn't tell me there was a problem and instead just hung on a blinking cursor. Booting into level 3 ('init 3') allowed me to get a command prompt where I could fix the various dependency issues again and do a 'yum update'.

While the hung screen is pretty serious (an average user might not be able to figure out the work-around), what annoyed me the most is how long it takes to do the first 'yum update'. That's because it updates EVERYTHING. First there was the 2 GB of download then the time to calculate dependency issues before it actually starts the update. What's the point of doing a DVD install if it is going to download everything again?

It would be nicer if there was an option of first download the system updates and then do application level updates in the background once the system is already up.