On Mon, Aug 23, 2010 at 10:14 PM, vefatica <> wrote:
> On Mon, 23 Aug 2010 20:42:42 -0400, DMcCunney
> <> wrote:
>
> |Out of curiosity, how often do you need to do it?
>
> Recently, once. *But if the functionality had been there for the last
> 20 years or so I probably would have used it a few times
"A few" != "many".
> |I recall seeing requests back in the old 4DOS days to build in
> |functionality that could either be provided by third-party
> |applications called from 4DOS, or implemented through 4DOS BTM files.
> |A lot of them struck me as "This is something else's job. *Use the
> |something else." cases, and so does this.
>
> TCC is chock-full of functionality which is provided by third party
> apps, or which can be accomplished with a script (often with no loss
> of speed). *A good example is DO's processing each line of the output
> of a command. *The good old fashioned way (a temp file) is much
> faster:
<...>
And the good old fashioned way is with us because MS-DOS didn't
support connecting the standard output of a program directly to the
standard input of another program the way Unix does things. (Since
DOS was single tasking, it couldn't. You had to use a temp file. I
would do that on a RAM disk to speed things further.)
> |I spend a lot of time playing in the Unix sandbox, and in that
> |environment, my reflex is to create a shell script akin to the above,
> |and not request that the bash maintainers make it a built-in.
> |Built-ins are called for where there is a significant performance
> |improvement, but that assumes it's something I'll be doing a *lot*.
> |(And is why, for example, the Korn shell added things like integer
> |arithmetic as a built-in, rather than calling eval as an external:
> |doing math in a script *did* happen a lot, like keeping count in a
> |loop. *The same goes for making echo a built-in, aliased to the
> |internal print command, instead of calling /bin/echo every time you
> |wanted to write something to the screen. *The performance increase
> |made it feasible to write entire applications in the shell.)
>
> You're pretty much stuck with that in the UNIX world. *How often do
> UNIX shells get new features? *I was a tcsh junkie 15 (or so) years
> ago. *I'll bet it hasn't changed much.
The most recent version of tcsh is 6.17.00, dating from 7/10/09. I
don't believe the functionality has changed in years. Most versions
are likely bug fixes or due to ports to other environments. (Like
*nix itself, tcsh tries to be portable, and runs on things that aren't
PCs and under OSes that aren't Unix. There's a Win32 port under
Cygwin, and I believe there's a MinGW version.)
The question is what new features a Unix shell *needs*. The shell has
always been two things: an interactive interpreter that serves as the
user's command line interface to the system, and a scripting language.
And since Unix was portable and ran on lots of architectures, and
since there were differences between Unix implementations (like BSD vs
SysV), there would be things you probably wouldn't *want* to try to
build into the shell because different *nixes did them in different
ways.
I started on the Bourne shell, but happily moved to the Korn shell
when it became fully sh compatible, and could be installed as sh on
most systems. The Korn shell added useful built-ins like print and
let, and improved the shell as an interactive interface by adding
things like command line history, recall, and editing.
I never cared for csh or tcsh because I wasn't thrilled by the script
language. Since most Unix systems used an assortment of Bourne shell
scripts as part of the infrastructure of the system, I saw no point to
learning another scripting language when the stuff I'd be concerned
with as a sysadmin was all Bourne shell.
These days, pretty much everyone is moving to bash. Bash tries to be
one-size-fits-all, and is what happens when you can't decide whether
you want a shell like the Bourne shell or a shell like the C shell,
and you compromise and create one that combines most features of both,
plus a few wrinkles of its own.
But the Unix philosophy has always been one tool for one job, and
using scripts to tie tools together when you needed to do more than
one job as part of your process. So "new features" will be things to
improve it as an interactive interface, like command history, recall,
and editing, or language constructs to improve it as a script
language. When you start wanting to add things that are normally the
province of an external program, instead of calling that external
program from a script, you are arguably missing the point of what the
shell is supposed to be.
> I think it's Rex's goal to (within reason) give the users what they
> want.
The question comes down to what TCC ought to be. From my perspective,
it's a shell, just like the Unix shells. It provides an interactive
command line interface to the OS, and a glue language to tie together
other tools to do more complex processing. At some point, you have to
draw a line, and say "That's not the command processor's job". The
question is where you draw the line.
Rex has been wonderful about giving users what they want, but the
80/20 rule applies. A lot of features people ask for require
significant effort to implement, and one question that has to be asked
is "Is this feature generally useful enough to *all* users to make the
effort worth it?" If I'm Rex, the requested feature is something that
will be used occasionally by a few users, and can be accomplished
already in a batch file using existing facilities, the answer may be
"no" unless the code required is trivial.
> And speed ... I'm obsessed with it a little more than most.
So am I, but I reserve my real desires for things that need it. If a
batch file or shell script I'll use once in a while takes 5 seconds
where a built-in would take a fifth of a second, I won't *care*. And
while the built-in may let me do on one line of code what the script
would require 5 for, the syntax is likely to be complex enough that it
won't be all that much faster to write it and get it right.
_____
Dennis
