Why questions don't get answered, or "No, I've already RTFM, tell me the answer!"

[David G. Miller (aka DaveAtFraud)]

mike.mccarty at sbcglobal.net 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