"Strong Scripting Skills" - a definition? - sunday

Mon Jan 26 08:21:13 PST 2004

On Sun, Jan 25, 2004 at 05:07:41PM -0800, Robert Hajime Lanning wrote:
> <quote who="Alvin Oga">
> > sometimes grep -v grep is needed, sometimes not... i donno why some
> > greps does it differently
> 
> Actualy, this is caused by a race condition.
> 
> ps -axuw | grep foo | grep -v grep | awk '{print $2}' | xargs kill
> 
> Each seperate command gets fork()ed and exec()ed with the pipes setup between
> them.
> 
> Now, the question is, will the "ps -axuw" initialize and read the process table
> before or after "grep foo" is exec()ed.  If before, then "ps -axuw" will not
> have "grep foo" in its listing.  If after, then "ps -axuw" will have "grep foo"
> in its listing.

I have to admit that maybe my standards are low -- too low -- but my
definition of "strong scripting skills" can be most easily explained by the
answer to this question:

Given a complex task in the command-line environment, do you know how you'd
automate it?

I'm not looking for an explanation of the difference between "ef" and
"waxu" for ps.  If you can say that your 'kill-by-name' command would have
a ps <that lists all processes> | grep <bonus points for using a regexp to
avoid partial matching> | awk | kill then you've got almost-strong-enough
skills, though that's an often-enough used example (and problem) that most
people have thought about it before.  

I find that people with strong scripting skills (my definition of the
world) are the sort of people who aren't going to be going "holy cow, how
do I get *that* done?," but are the sort of people who can say "yeah, it'll
probably take chaining these commands together."  If they don't know the
exact syntax -- whatever.  That's what man pages are for.  

Oh, and portability is for, umm, heterogeneous systems.  It's not required
(and if you're not designing for a heterogeneous system, I tend to think it
can be a bad thing).

-roy