mike.mccarty@xxxxxxxxxxxxx wrote:
Les Mikesell wrote:
On Fri, 2005-12-30 at 16:44, Mike McCarty wrote:
John Summerfied wrote:
I reckon your expectations are a little steep.
I don't think you will find the kind of information you desire
comes with any implementation of any programming language,
certainly for peecees. Have you noticed the proliferation of
Windows books?
Au contraire, mon ami. Borland C, for example, comes with a nice
tutorial on the C programming language.
But that doesn't tell you anything about the existing system
utilities or how to use them. Most of the things you might
want to do are already handled nicely by programs included
with the system. If you only know a low-level tool like
C, you are doomed to re-invent a lot of things unnecessarily.
Not at all. I just don't glue them together with long complicated
shell scripts.
I'm not against anyone learning how to use all the tools available
to do the things they do best. And not all languages are equally
suited to any given task. Using the shell as a programming language
is undesirable for a number of reasons, among them are
(1) it unnecessarily complicates the command line parser. Since the
CLI gets sooo much use it is desirable to make it simple, hence
correct
(2) Shell scripts are inherently less portable between systems
than languages designed with portability in mind, like C.
(3) Each part of a system should do the things it does best. I
find that when I need something relatively complicated, but
not enormously complicated, often a program written in more
than one language is best. I use the shell to process the
directory tree, and use the tools available where I can,
but if I need special processing then I write a one-off
C program to do the specialized processing, which gets called
perhaps like this:
$ find /path/to/somewhere -name "file*globbing*stuff*" -print |
my_special_program \;
I might even use a loop or two in the shell stuff.
But I do *not* do the complicated logic using the shell.
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
Funny. At a prior job, I ended up slowly implementing a document
management system a few features at a time in c-shell. Nobody ever
said, "Go develop a document management system," it was just develop yet
another shell script that does this or one that does that. The final
effort was about 3,500 lines of csh that was never intended to do
anything but support the folks using it (i.e., it didn't need to be
portable). Likewise, I just used features of csh that were also easily
exercisable from a command prompt (makes testing a lot easier) so I
would hardly consider that requiring the shell be extensible to this
sort of effort overly complicated the shell.
On the other hand, this would have taken a programming staff of probably
ten to twenty people working over several years to develop in anything
other than a scripting language. Anything other than an iterative, "Is
this what you want?" development approach also would have been futile
since the people I was supporting didn't really know what they needed
the system to do but had some really good ideas about what would make
their job easier and more accurate.
BTW, the guy who replaced me said he frequently referred to the overall
script set as kind of a guide to Unix commands since I used (in his
opinion) about every command possible at some point. The system
remained in use until the venture using it was disbanded. The company
had purchased Documentum for this purpose but was never able to
implement the customizations needed (visual basic) for it to support
what we were doing. Given experiences like this, I find most people who
disparage shell programming to be at best uninformed.
Cheers,
Dave
