HP3000-L Archives

April 1998, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Jeff Woods <[log in to unmask]>
Reply To:
Jeff Woods <[log in to unmask]>
Date:
Fri, 10 Apr 1998 15:07:23 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (61 lines)
[Note: The following is, even more than usual, my personal verbal
meandering and as such may not be taken as official dogma of anyone or
anything, not even the author.  And, as always, feel free to hit the Delete
key at any time.]

At 10:45 AM 4/10/98 -0700, Tim Ericson wrote:
>Command files are great, piping would be nice, but we can't let
>Jeff get bored!  :-)

Why do I think that's not likely to happen any time soon?  :)

>SO, what about:       User Defined Functions?

[Good "blue sky" ideas about user defined functions snipped.]

>So what say youse guys?  Am I thinking WAY too much and should I
>just stick to COBOL?

We already have this, and pipes, and iteration on files in a fileset, and
lots of other very handy features.  They are part of the Posix shell...
Rather than investing lots of development resources in the old familiar CI
(and having to go to great lengths to prevent breaking some existing
hare-brain script somewhere ;) it seems to me that we would likely benefit
more by each taking the time to become more familiar with the features of
the Posix shell (which are almost identical to the Korn shell aka "ksh")
and promote the improvement of issues with the shell such as performance
and integration with the CI.

These changes would provide better long term return because they would give
us all more functionality with less effort and less danger of negative
impact on old applications.  In addition, they would likely remove more of
the stumbling blocks which are obstacles hindering the progress of some
"MPE types" toward the shell and hindering the acceptance of some "non-MPE
types" (aka "Unix types" and other homonyms in some circles) because IMO
the shell *does* seem rather "chunky".  It's not so much lack of features,
as it is lack of integration with the "MPE part" of MPE and sluggish
interactive response (such things as slow forks and intermittent character
dropping, etc.)

BTW, I'm not trying to say that improvements in these areas haven't been
coming.  On the contrary, I know that it's something getting attention.
I'm just saying that instead of trying to turn the MPE CI into the Korn
shell, we already have a good shell, let's see if we can make it more
seamless with the good things we have in the CI and remove the obstacles
that are perceived in it.  I suppose, this is also just as much a
suggestion that most of us could get more value from the shell than we do.
I know it looks cryptic at first (few dozen ;) glance, but it's fairly well
documented (several books exist) and there is lot's of expertise out there
in the Unix world on it.  Let's leverage what of that we can.  Who knows...
perhaps we might even convert a few more of those recent college grads that
MPE really is the best of both worlds, all things considered.
--
Jeff Woods
[log in to unmask] at Tivoli Systems
[log in to unmask]   at home  [PGP key available here via finger]

Haiku by Rahul Sonnad:
   There is a chasm
   of carbon and silicon
   the software can't bridge.

ATOM RSS1 RSS2