New (GNU) kernels--what I think

[Doug Gwyn]

In article <2501 at gandalf.UUCP> ml at gandalf.UUCP (Marcus Leech) writes:
> Options should be case insensitive.

Why?  Nothing else in UNIX is.  It isn't even clear how to perform
case mapping in some locales, although presumably option letters
(not their arguments) would be parsed in the "C" locale for which
it is clear.

I like to use upper-case option letters for local extensions to
standard utilities, on the theory that they won't conflict with
future versions of the utility as the vendor adds options.  ("ls"
is an obvious exception; it already has more than 26 standard
options.)

> Options should be complete words, with a minimum-unambiguous scheme ...

I think there is a fundamental misconception here, namely that the
Bourne shell-based software developer interface to UNIX can be made
appropriate for general users through small changes like this one.
I don't think general users should be subjected to an environment
that makes such demands on their understanding of so many system-
related concepts.  Far better to provide them with menus, icons,
etc. plus instructions on how to enter the developer environment
when they have a real need to do so.  (Most users should never need
to do so.)

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

Which means that you cannot restrict the directory entry names,
beyond outlawing / and NUL (and it's a shame to have to outlaw those).

>  The notion of CLISTs should certainly be re-visited, and probably abandoned.

In favor of something like streams.

>    - 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. Some other mechanism may suggest itself.

We already have far more useful forms of command history available via
various shells (tcsh, BRL sh, ksh, etc.) and terminal facilities (mux, etc.).

>  There ought to be a "resource" allocator that is responsible for allocating
>  peripherals to users.

Yes, and this can be done entirely in user mode.  If anyone actually starts
such a project, contact me for design notes I have sitting around.

A "terminal" allocator would be exceedingly helpful, especially for pty and
window management.  The terminal manager would have a more specific role
than, say, a magtape device allocator, in that it would keep utmp updated
(or the equivalent), slip appropriate modules onto the initial stream, etc.