Shells, features and interaction

[David Korn]

> One final note:
> 
> text	data	bss	dec	hex
> 27648	1024	2568	31240	7a08	/bin/sh		8th edition shell
> 67584	2048	5740	75372	1266c	/bin/csh	C shell
> 81920	3072	9224	94216	17008	/usr/lbin/ksh	Korn shell
> 
> 					Rob Pike

I will not delineate here the reasons that ksh is the most widely used
shell within AT&T even though it is not officially supported.

Choosing a shell based on size of the text is like chosing a terminal
based solely on its weight.  The primary reason that the size of ksh
is large is because of the editing options.  Aliases take only about 1K
of text space in ksh.

Functions are not a complete replacement to aliases any more than
window managers provide a complete replacement to job control.  (I use
job control with my Apollo and 5620 just as often as I did with my
HP-2621.)

Aliases allow you to do things that you can't do with functions.  For
example, using aliases you can write a command which passes its arguments
without file name generation.  I can write a command, remote, such that
	remote x ls -l /bin/*
will expand the file name pattern on the remote machine.  With functions
this is impossible since file name generation occurs before the function
is invoked.  A complete MS-DOS script emulator was written in ksh and
aliases were needed in several places that functions couldn't be used.

The System V implementation of functions has the following deficiencies
most of which exist in the 8th. edition Bourne shell:

1.	No local variables
2.	name=value parameter lists remain after function completes.
3.	Cannot trap return from functions for cleanup of resources.
4.	Cannot separately trace function executions.
5.	Function names conflict with shell variable names.
6.	You can't write a function to replace a built in command. (This
	has been fixed in 8th edition)
7.	Function names must be alpha-numeric.

If the collection of functions is large (which is common), exporting by
deparsing functions and passing them through the environment is sure to
be more expensive in any current version of UN*X than reading a startup
file, as in ksh.  Even if the copying is speeded up, as it has been for
8th edition, the environment is generated for each command, and copied
to each created process.  If we assume that about 10% of processes created
by the shell are shells, then the functions are deparsed and copied 10
times for every shell invocation.  Ksh reads a file for startup and uses
block buffering.  I have seen startup files of several thousand bytes so
at a minimum the 5120 limit on environment sizes would have to be
increased substantially.

For the sake of simplicity, the Bourne shell is riddled with little things
that confuse the user.  Consider the following list of annoyances of the
'simple' Bourne shell:
1.	Can't kill any processes if you have reached your process limit.
2.	sh script doesn't perform path search for script.
3.	You can not < abc* as short hand for < abcdefghijkl.
4	You can write ${9} but not ${10}.
5.	x=`\$HOME` causes $HOME to be expanded
6.	Unmatched quotes give EOF unexpected, which is not very helpful.
7.	You can not read a line ending in \ without reading two lines.
8.	PATH=/bin:/usr/bin: will not search current directory last.
9.	Cannot set traps by name.
10.	name=value command has different semantics for built-ins.
11.	No obvious way to find the parent pid of the shell.
12.	Gaping security holes which get worse with exported functions.
13.	Pipelines cannot be timed.
14.	| and ^ are used as synonyms.

One final note: (in grams)

display	mouse	keyboard dec	hex
 4989	0	1134	 6123	17eb	ti745	  Silent 700
16329	0	1588	17919	45fd	hp2621p	  Hewlett Packard
26762	255	2268	29285	7265	dmd5620   Blit

David Korn
ulysses!dgk