New (GNU) kernels--what I think

[Peter da Silva]

In article <2501 at gandalf.UUCP>, ml at gandalf.UUCP (Marcus Leech) writes:
>  Options that perform the same function in different
>  commands should have the same names.

Within reason. -v should always be verbose, say.

>  Options should be complete words,

No, I think not. We still want to run UNIX shell scripts.

>  Commands should all use perror(), wherever possible.

Damn straight. I'm amazed AT&T hasn't taken a summer hire and just had them
go through the sources and fix this. It wouldn't take more than a couple of
months.

>  In general, the messages coming out of programs should walk that
>  fine-line between brevity, and useful information content.

Also the output of a program should, whenever possible, also be acceptable
as input. env(1), for example, should properly quote arguments. stty(1) should
dump the semicolons and the verbose 'speed 9600' stuff unless it's willing
to accept it as input. Stty -g isn't a solution to the problem... what if
you want to cut and paste? Windowing environments are becoming more common
and this would make the command more window-friendly.

>   Restrict filenames to alphabetics,numbers,and punctuation, keeping in
>   mind national character sets.

What do you mean by this? What's an example of a filename that isn't made
of alphabetics, numbers, and punctuation? What's wrong with a file called
"Error Log 23 Jan 1989"?

>   I'd make a sweep of the I/O system to generalize non-blocking I/O, and
>   make sure it WORKS in all the places you'd expect it to work.  I'd probably
>   make select() available.

I'd hope for something more general than select().

>   I'm not sure how wonderful the shm*() calls are.  TCP/IP networking is a
>   must--it should be tunable at run-time (I'd like to see the KA9Q code in
>   the kernel, with some performance enhancements).

This doesn't make sense when taken together with your call to remove I/O
from the kernel.

>     - History-next
>     - History-previous
>   The "History" characters should do something (post an interrupt?) that
>   causes the current command interpreter to place appropriate history into
>   the tty driver input buffer.

No, they should pull the next or previous lines from a circular buffer in
the driver. If you're going to duplicate the history mechanism in all
your programs you might as well just take the history code from ksh and
put it in a library.

>   The current ad-hoc schemes used by cu and uucp, for example, should be
>   changed to use the "resource allocator".

Actually, we find that LCK files work just fine for allocating all sorts
of resources.
-- 
Peter da Silva, Xenix Support, Ferranti International Controls Corporation.

Business: uunet.uu.net!ficc!peter, peter at ficc.uu.net, +1 713 274 5180.
Personal: ...!texbell!sugar!peter, peter at sugar.hackercorp.com.