Kernel Hacks & Weird Filenames

Dave Decot decot at hpisod2.HP.COM
Wed May 4 05:18:40 AEST 1988


> I think the most wonderful thing about UNIX is it's generality
> and elegance. Sadly, people who don't appreciate that, add
> gratuitous options to cat(1) and ls(1), and now (horrors!)
> make proposals that unprintable filenames be disallowed.

I suppose I am the one who first proposed this here (at least recently).  
If you read it, you saw that what I proposed is that it be POSSIBLE TO ASK
THE KERNEL to prevent a user-specified set of characters from being allowed,
*not* that the kernel be hardwired to make this decision once and for all.

> To understand the UNIX philosophy, we must go back to the original
> source. The following is from the paper, "UNIX Implementation"
> by Ken Thompson:

I am familiar with this paper and agree substantially with what it says.

> >The kernel is the only UNIX code that cannot be substituted
> >by a user to his own liking. For this reason, the kernel
> >should make as few real decisions as possible. This does not 
>                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Important point!

I agree that this is important.  Currently, the kernel has decided
that any old random garbage may be used for file names.  This allows for
the needs of all users, certainly.  It also GETS IN PEOPLE'S WAY more
often than it HELPS ANYONE.  My proposal was to be able to ask the kernel
to be more restrictive.  Many people have pointed out that hacking up 
all the shells and libraries and application programs to prevent
garbage file names is the wrong way to do this, since it spreads the
enforcement all over the system instead of localizing the policy.

> >Even so, if "the way" is too radical, no one will follow it. Every
> >important decision was weighed carefully. Throughout, simplicity
> >has been substitued for efficiency. Complex algorithms are used
> >only if their complexity can be localized.

Note that my suggestion was not for a "complex algorithm"; once installed,
it requires one additional array access and one bit-masking per character
to test the basename of files being created for the first time.

This is localization of complexity.

> If you want to protect naive users from unprintable filenames, then
> by all means write a special shell or relink your utilities with
> a special version of the C library, but don't put that decision
> in the kernel.

Putting enforcement of usable file names everywhere else in the system
does NOT localize complexity.  The only reasonable place to prevent
the existence of garbage file names, if this is desired, is to enforce
it where all new file names get added to the system.

> I think the proposal that unprintable filenames be disallowed by the
> kernel follows from a VMS/IBM mentality. Sorry to be so harsh, but
> it totally goes against the whole spirit of UNIX.

I have never used a VMS or IBM system, and am therefore unfamiliar with
this mentality to which you refer.  I have used UNIX and designed, written,
and tested system software for UNIX for nine years.  I am thus familiar
with the "spirit of UNIX", and know that it means slightly different
things to different people.  We agree that there are certain
principles as you have quoted from Ken Thompson that should be preserved,
and, as Ken says, "weighed carefully".  We apparently do not agree on the
relative weights of purity of design against usability of the system.

> The kernel should allow very general things. It is all the crap
> above it

You seem to take a rather dim view of user-space software in general.

> that should "protect" the user. This is because, you
> and I differ whether this "protection" is needed or not. You
> can have all the "protection" you want, but don't force it
> on me!

I don't think anyone intends to force it on anyone.  We just think it
should be configurable so that those who desire to use UNIX can do so,
and those who would rather preserve its moral purity can also do so.

> 		      Naim Abdullah
> 		      Dept. of EECS,
> 		      Northwestern University

Dave Decot
Hewlett-Packard Company
hpda!decot



More information about the Comp.unix.wizards mailing list