Sunday July 18, 2004

Todd Wins The Open (Todd who?)

The Open Golf 2004

Todd Hamilton (who?) won his first major! Holding off no less than world no. 2 Ernie Els in a 4 hole playoff.

Todd led throughout on Sunday. Still led by 1 after Ernie birdied 17th, Todd start off 18th with a bad tee shot into thick stuff and a worse second short of the green and almost into the crowd, a free drop and a chip that went long, end up making bogey; while Ernie GIR but missed a makeable birdie which could have ended the match.

The 4 hole playoff goes from hole 1, 2 and back 17, 18. A mistake in 17th tee par 3 left Ernie with the only bogey of the duo and cost him the claret jug.

Phil Mickelson didn't really choke this time (well the monkey's really off his back after Masters) but still came up short and played second fiddle again.

Tiger, yet again, didn't matter with a disappointing +1 on Sunday and finished 9th.

Lee Westwood seemed to be inspired and shot 67 to finish 4th; Davis Love too finished with 67, who wasn't shown much on prime time TV coverage climbed to 5th.

(2004-07-18 10:53:46.0) Permalink

Wednesday July 14, 2004

ksh scripting #4 : list elements v7 and v8

Alan offered cool advise on ksh scripting #3 with pl.sh using "IFS" and "set --".

... and I dig!

So I adapted pl.sh into a shell function. My initial concerns that IFS is not taken in local context of a function was valid afterall. IFS is global and most certainly not just another variable. It got confusing when echo $IFS doesn't show anything and I thought it's spaces. set | grep IFS shows differently. It got even more mysterious when the function was invoked again but produce different result. Only after a bunch of almighty debug printf (ok I used echo) that it became clear IFS was causing my confusion. Just to make matter more difficult for myself I tried to be fancy and do set -- $@ directly. That certainly doesn't work. The moment IFS is set, substitution for $@ no longer shows the char that's IFS but instead, space is substituted!

Here's pl7() which adapted the set -- trick that works:

#
#  pl7 - print list elements delimited by '|'
#
function pl7 {
  l=$@
  IFS='|'
  set -- $l
  for e
  do
    echo $e
  done
  unset IFS
}

And to add some flexibility, I can cater to user specified delimiters which would have been otherwise messy to do in pl version 1:

#
#  pl8 - print list elements, $1 is delimiter
#
function pl8
{
  d=$1
  shift
  l=$@
  IFS=$d
  set -- $l
  for e
  do
    echo $e
  done
  unset IFS
}

Give it a go:

$ pl7 "lp|x|71|8|Line Printer Admin|/usr/spool/lp|"
lp
x
71
8
Line Printer Admin
/usr/spool/lp
xxx


$ pl8 ":" lp:x:71:8:Line Printer Admin:/usr/spool/lp:
lp
x
71
8
Line Printer Admin
/usr/spool/lp
xxx
$ 

I guess my intention was clear, in that I'm trying to let ksh do all the work whenever I can avoid a process invocation. Otherwise, it's really much easier to just awk it.

$ head -1 /etc/passwd | nawk -F':' '{while (++i<=NF) print $i}'

 or a bit more readable

$ head -1 /etc/passwd | nawk -F':' '{for (i=1;i<=NF;i++) print $i}' 

PS: Okay why version 7 and 8? it took me that no. of iteration to figure out IFS. ;)

ksh scripting flashback: #1 #2 #3

(2004-07-14 00:00:04.0) Permalink Comments [3]

Friday July 09, 2004

ksh scripting #3: list elements

It seem unavoidable, at some point there is always some kind of list that needs spliting.

#
#  pl - print list elements delimited by '|'
#
function pl {
  l="$*|"

  while [ "$l" ]
  do
    e="${l%%\|*}"
    l="${l#*\|}"
    echo "$e"
  done
}

Here's to give it a go:

$ head -1 /etc/passwd | sed 's/:/|/g'     
root|x|0|1|Super-User|/|/bin/ksh
$ 
$ pl `head -1 /etc/passwd | sed 's/:/|/g'`
root
x
0
1
Super-User
/
/bin/ksh
$ 

Why '|' as separator? Well, when was the last time you see this '|' thing in the English language? And, when was the last time you process a bunch of shell command pipelines all concatenated together into a list to be processed? I supposed you get them more often with each pipeline on a separate line, as in a shell script (?!); which you could readily process with read, grep, awk, sed and a zillion other utilities.

Why not ':' as in /etc/passwd? I have scripts that process list of URL's, so 'http://...'! Not very convenient isn't it.

ksh scripting flashback: #1 #2

(2004-07-09 00:00:03.0) Permalink Comments [1]

Thursday July 08, 2004

ksh scripting #2: unix friendly filename

Every time I rip and encode tracks from my CD collections (yes I still buy them) to mp3, I had the need of getting a unix friendly filename from the human readable title since I use Solaris to do everything. I typically grab the titles from a free cddb out there that happens to have my album's details. But these come in various formats such as:

9. title of track nine
10) track-ten's title
11: track eleven title & nothing else...

While I need them to be unix friendly, such as:

9:title_of_track_nine
10:track-ten_s_title
11:track_eleven_title_+_nothing_else___

So I script it with the help of sed(1), and what a monster I've created!

#!/bin/ksh

cddb=$1

ttlist=`sed 's/^[   ]*//;/^$/d;/^[^0-9]/d;s/[	]*$//;s/[   ][	]*/ /g;\
/^[0-9][0-9]*[. _    :-)]/s/[. _ :-)][. _    :-)]*/:/;s/[".]//g;\
y/ '"'"'&\//__++/' $cddb`

#   remove leading spaces and tabs
#    s/^[   ]*//
#   remove blank lines
#    /^$/d
#   ignore lines not beginning with a number
#    /^[^0-9]/d
#   remove trailing spaces and tabs
#    s/[    ]*$//
#   compress 1 or more adjacent white spaces
#    s/[    ][	]*/ /g
#   replace characters delimiting track no. from the title, with a single delimiter
#    /^[0-9][0-9]*[. _	:-)]/s/[. _ :-)][. _	:-)]*/:/
#   remove characters that won't look good if transformed to "_"
#    s/[".]//g
#   transform space and special chars to shell friendly chars
#    y/ '&\//__++/

# create title[track] array elements
for tt in $ttlist
do
  let "track = ${tt%%:*}"
  title[$track]=${tt#*:}
done
    :

    :

I'm not even sure if I understand this now that I looked at it again. :(

The for loop that followed put the track title into an array indexed by the track no., nice and neat for whatever I want to do next.

ksh scripting flashback: #1

(2004-07-08 00:00:02.0) Permalink Comments [5]

Wednesday July 07, 2004

ksh scripting #1: ME=${0##*/}

True to the tradition of unix, this is as cryptic as it gets, but... elegant [GEEK!]

  #!/bin/ksh
  ME=${0##*/}

ME here gets the name of the script without the path, effectively doing a basename(1) without the burden of a fork and exec process invocation.

${0} - is command line token 0, i.e. the script filename
## - strips the largest leading string matching the pattern that follows
*/ - this pattern with ## matches everything upto and including the last '/', this is shell wildcard (patmat), not regex

For those who like filename with obvious indication of it's genre, e.g. blah.sh , do this:

  #!/bin/ksh
  ME=${0##*/}
  ME=${ME%.*}

% - strips the smallest trailing string matching the pattern that follows
.* - this pattern with % matches the last '.' (dot is not a wildcard in shell, '?" is) and upto the end of string

I always use $ME in my usage() function,

  usage () {
  cat <<__UsageEnd__
  usage: ${ME} [options] args...
    options:
      -a  ah
      -b  blah
  __UsageEnd__
  }

and any error output,

  perr () {
  echo "${ME}: ${SEVERITY}: ${MSGTXT}"
  }

Since my job does more code reading than writing, what's left is the occasional need to automate some test, so shell does it just fine. Instant and disposable (i.e. no worries about reusable values). Nevertheless, there are a few tricks here and there that I like to remember.

(2004-07-07 00:00:01.0) Permalink

Monday July 05, 2004

After Blackout ... Smallville gets a re-run

After the Great Singapore Blackout ('ala Great Singapore Sale), the local free-to-air TV actually decided to re-run the last episode of Smallville. Why am I not particularly excited (I thought I should)? Must be the boring ending that I managed to catch as my area was the first to get electricity back.

(2004-07-05 01:23:45.0) Permalink