Bourne shell modifications, past and future

[Dave Stewart]

In article <847 at whuxl.UUCP> mike at whuxl.UUCP (BALDWIN) writes:
>I think providing *both* aliasing and functions is a misfeature!  Why have
>two inconsistent ways of doing the same thing???
> ...
>Back to my first point:  please don't implement something 2 or 3 times
>in different ways!  Functions subsume aliases very nicely, so chuck
>aliases!

	The same thing could be said for the "for" "while-do" and "do-while"
constructs in C.  It can be proven that any of these can be subsumed
by one of them - so why have all THREE ways of doing the same thing?  Well,
history for one thing and programmer convenience for another.  That's why
you provide both aliases and functions - aliases have a history (excuse the
pun) in csh.  Having both is more convenient.

	In ksh, aliases take on other roles as well: tracked aliases
are as a replacement for the command hashing of csh.  There are also a
handful of aliases predefined upon shell invocation which (in a sense)
provide the user with more things that look like builtins without
actually adding more builtins.

	I think most people who have both aliases and functions available
use aliases as command-name macros and shell functions like programming
language functions.  Well, the analogy isn't perfect, since one also
has shell scripts to act as "functions", but I believe the concept is
transferable.  Do I want to chuck out macros because I have functions
available?  Heck no.

	Finally, there is a line in the ksh intro paper that reads, "Functions
are more general than aliases but also more costly."  Well, I guess
that's implementation-dependant, but intuition would tend to support
this, even when one considers that functions usually take up more text
chars before being read.

-- 
David C. Stewart                          uucp:    tektronix!davest
Unix Systems Support Group                csnet:   davest at TEKTRONIX
Tektronix, Inc.                           phone:   (503) 627-5418