SPUG:~damian/bin scripts.

[Dan Sanderson]

I would not want to discourage Damien from publishing his scripts, but
I'm personally looking forward to implementing some of the more
inspiring ideas myself as instructive exercises.  I've never used
Term::ReadKey before, for example, and would enjoy making my own getraw
just to try it out.  Not that Damien's versions wouldn't also be
instructive to see, of course.

One of the central themes of ~damien/bin was TIMTOWTDI, but the best way
for you to do things in your environment is *your* way.  While the theme
seemed rather obvious at first, the presentation hit me at an angle I
didn't expect.  Like any newbie, I used to try to do things the way
everyone else did, figuring that the problems of the computing
environment had been re-visited countless times by people capable of
making intelligent revisions, and so the traditional uses of the
traditional tools were probably a pretty good way of doing things and I
should try it that way.  If I ever felt like a 15-year-old Unix tool 
could be improved, I thought, I should at least research a better
existing implementation before building my own.  Then perhaps at some
time in the future, I could knowledgeably decide that implementing a
particular change, at least in my own environment, would be worth the
effort.

What ~damien/bin reminded me is that the ease with which tools and
wrappers can be built with Perl drastically affects the cost-benefit
analysis of when to decide to just do it yourself.  I've customized my
Unix work environments many times over the years, but I must admit it
never occurred to me to scrutinize the very building blocks I was
using.  Of *course* I can add custom functionality to the 'cd' command! 
Of *course* there ought to be a command that generates files of dummy
data, I do that all the time!  Of *course* tar ought to be able to
figure out its own execution mode from the filename!  With such a
powerful sword in my hand, why on Earth would I allow it not to?

I imagine this might be a newbie lesson to some degree, but it's still
an important one.  Especially when new to a technology, I've always
paranoically exaggerated the costs of customization:  I might train
myself to my customizations and become less effective without them-- but
of course I would, customizations are powerful.  I might re-invent a
wheel, perhaps even one that was already in my /usr/bin/ directory and I
just didn't know about it-- but when I do discover it, I could always
decide which one I like better and just use it.  I might separate myself
from a standard environment enough that I might not be able to assist or
support others in their environments-- all the more reason to write my
customizations myself, so I understand what steps I'm saving myself from
having to do.  I might need to write software that works in a standard
environment for distribution purposes-- but that's when I learn enough
about /bin/sh scripting to meet the requirements, then go back to my
luxurious Perl-enabled mansion to live the rest of my life.

So it was refreshing and inspiring to see how an experienced
professional sets up their environment to get stuff done.  I can imagine
a series of similar presentations from other experienced professionals,
especially with different daily needs, being similarly useful and
inspiring.  Home decorating ideas with Perl.  It's a Good Thing.

What's in *your* ~/bin directory?

-- Dan


On Mon, 2003-01-20 at 18:50, Brian Maher wrote:
> Damian's talk at this months SPUG meeting was great!
> 
> I was interested in acquiring some of the scripts Damian presented at 
> this months SPUG meeting.  Specifically, I would like to see these 
> scripts:
> 
> -cd/cdd/cdd?
> -pmd
> -killproc
> -entar/untar
> -getraw
> 
> Has Damian posted these anywhere?
> 
> Thanks!
> 
> _____________________________________________________________
> Seattle Perl Users Group Mailing List  
> POST TO: spug-list at mail.pm.org
> ACCOUNT CONFIG: http://mail.pm.org/mailman/listinfo/spug-list
> MEETINGS: 3rd Tuesdays, U-District, Seattle WA
> WEB PAGE: www.seattleperl.org
>