So you’ve got a program that spits diagnostic output, but may take a while between actions. You don’t want to have to sit and watch it to see how long it takes, but it doesn’t provide timestamps.

Pipe the output to this perl one-liner:

perl -ne ‘print “[”.time().”] ” . $_’

You will get output a la:

[1160497217] Resolving kradeleet.com… 209.216.203.249
[1160497217] Connecting to kradeleet.com|209.216.203.249|:80… connected.

If you eschew Unix timestamps, try

perl -ne ‘print “[”.scalar(localtime).”] ” . $_’

which cleverly provides:

[Tue Oct 10 09:33:58 2006] Resolving kradeleet.com… 209.216.203.249
[Tue Oct 10 09:33:58 2006] Connecting to kradeleet.com|209.216.203.249|:80… connected.

Unfortunately, better timestamps in Perl take us out of one-liner territory. You could try

perl -ne ‘printf (”[%5\$d/%4\$d/%6\$d %3\$d:%2\$d:%1\$d] %10\$s\n”,localtime,$_)’

(the slashes are necessary for the shell to avoid expanding the $’s as system variables)
But this will give you:

[9/10/106 9:29:19] Resolving kradeleet.com… 209.216.203.249
[9/10/106 9:29:19] Connecting to kradeleet.com|209.216.203.249|:80… connected.

which is the wrong month (January=0, October=9) and weird-looking year (real year - 1900). You’ll have to twiddle the output array of localtime() to fix these (as everyone who uses localtime() inevitably does).