NYCPHP Meetup

[James Wetterau]

David Mintz says:
...
> 
> Suppose -- just hypothetically -- I write a shell script that greps the ps
> output for a user-specified string. I could say, here's my shell script
> and you're welcome to use it, but it depends on ps and grep being
> installed on your system. Is it not a good shell script? Should it have
> its own ps and grep functionality built in, independently?

I would say it should certainly not have that functionality built in,
since anywhere you can run your shell script, including Windows using
Cygwin or the like, you can get ps or grep.  So why reinvent the
wheel?  The codebase behind ps and grep is likely to have benefited
from all kinds of improvements over the years.  However, compatibility
is a somewhat knotty problem, which things like Posix attempt to
address.  There will always be tradeoffs in such decisions.

An example of an interesting decision to the contrary occurred when
Tom Christiansen of Perl fame got fed up with the absence of
consistent shell tools for use in Perl scripting of systems tasks.  He
spearheaded an effort under the name "Perl Power Tools" to re-write in
pure Perl a lot of the typical tools you might find in /bin, /usr/bin
and /usr/local/bin on a BSD system.  The idea was that when done,
anywhere you could run Perl you could always have cat, grep, find,
tset, stty, ls -- even awk -- by loading the appropriate Perl module,
in case the tools weren't available in native C implementations.

I'm not sure what came of that project.  However, I think it is
interesting that the effort recognized the value of the particular
historic Unix tool set and didn't attempt to redesign them.  The
notion was to deal with systems where there might well not be a a ps
or grep yet, which is probably not the case when shell scripting.

Another interesting alternative approach is embodied in the "BusyBox"
tool: http://www.busybox.net/downloads/BusyBox.html

BusyBox unifies the executable, but keeps the separate interface.
BusyBox is also meeting a niche need: very constrained memory
environments that want the traditional Unix toolkit.

In my humble opinion, issues of what to keep separate, what to unify,
where interface lines should be drawn, when to reuse, when to
reimplement, and how best to modularize code are the most complex area
of freedom to deal with intelligently in just about any programming
task, and there is no simple rule for doing it right.  Your individual
situation should always guide your decision.

> fwiw, I'm not arguing for argument's sake, just trying to learn stuff from
> y'all. thanks.
> 
> On Fri, 5 Dec 2003, David Mintz wrote:
> 
> > On Fri, 5 Dec 2003, Chris Shiflett wrote:
> >
> > > I think the argument goes something like this:
> > >
> > > Each module should do one thing and do it well (ala Unix philosophy). For
> > > example, on a Unix system, I can grep through the output of ps by doing
> > > something likethis:
> > >
> > > ps | grep foo
> > >
> > > Both grep and foo are independent, but they can be combined. Code can wor
k
> > > in much the same way. If grep cannot be used without ps, or if ps cannot
> > > be used without grep, this would be seen by many as a shortcoming.
> > >
> > > Hope that helps. I can elaborate, but that's the basic idea.
> >
> > I get it. Thanks.
> >
> > 	David
> >
> > _______________________________________________
> > talk mailing list
> > talk at lists.nyphp.org
> > http://lists.nyphp.org/mailman/listinfo/talk
> >
> 
> 
> ---
> David Mintz
> http://davidmintz.org/
> ATTN Everybody: dmintz at panix.com will be unplugged as of 01-Dec-2003!
> Please use dmintz at davidmintz.org
> 
> 
>         "Anybody else got a problem with Webistics?"
> 
>                 Sopranos 24:17
> 
> _______________________________________________
> talk mailing list
> talk at lists.nyphp.org
> http://lists.nyphp.org/mailman/listinfo/talk