Re. http://mail-index.netbsd.org/netbsd-help/2003/02/12/0006.html

One thought (I'll put it first, since it should have been my first
thought...though honestly it is an afterthought):

Are you worried about speed because you just want it to be fast
and figure that a few milliseconds (or less?) are worth saving?
Or do you *know* that this is something that *needs* to be faster?

At the risk of insulting your intelligence: Our guesses about where
performance is lacking, and whether something is "fast enough" are
often not so good.  And premature optimization can leand to more
time and trouble (and possibly even *less* optimal performance).


That said:

I'd think that piping into tr is probably pretty efficient.  Although
both take somewhat complicated options, they are still reasonably
specialized tools.

If you really do want something better, I have a few suggestions.
In order of decreasing speed that I'd expect:

 * A simple C program to do *just* what you want.  Should be short
   (shorter than this email), portable, and about as fast as you
   can get unless you want to hand-write assembly or perhaps do your
   own date formatting from a raw time-in-seconds stamp.

   See the ANSI C time/date functions (e.g., strftime()).

 * Tweak the date command with a new option for your needs.  (^&

 * A simple AWK program, such as:

     awk 'BEGIN {print tolower(substr(strftime(), 5, 3))}'

   ...simpler than the C counterpart (a little).  Probably measurably
   slower than the other two suggestions, but MAYBE measurably faster
   than date | tr, since the latter involves two processes and a pipe
   for communications.

"Measurably faster/slower" means (as I used it above) that if you
loop over it a few thousand times, you can measure the diference.
Not sure if timing a single iteration would produce reliable
information.  Also, context may be important: If memory is tight,
code-pages for programs may be paged out (or more likely to be
paged out).  Paging them back in could change the relative measurement
in "real life" vs. a tightly looped benchmark.

Now, to return to the first point above: Has the usertime required
to write this (and for you to read it) exceeded the expected usertime
spent waiting on date | tr?  (^&


-- 
  "I probably don't know what I'm talking about."  --rkr@olib.org