🚀 go-pugleaf

   Resent-Date: Fri, 28 Aug 1992 08:13:18 -0400
   Date: Fri, 28 Aug 1992 08:13:18 -0400
   From: karl@claude.cs.umb.edu (Karl Berry)
   Sender: gnulists@ai.mit.edu
   Resent-From: bug-gnu-utils-request@prep.ai.mit.edu

   I don't understand the argument that we don't know what
   / means to the kernel.  / means what we all know it means.

Clearly not, because / at the end of a directory causes a failure if
it's just a file, and this is important.  The file utilities assume
that nobody cares about this distinction, or that they just don't know
about it.

   I don't think it's fruitful for the GNU file utilities
   to worry about running under non-Unix-like operating systems.
   Or is this not what you're thinking about?

It's running on the kernel that we care about, and it's here that the
file utilities *remove* a useful bit of functionality.

   Thomas, you seem to be worried about some abstract principle.
   I agree with the principle (in principle); in practice,
   I want the programs to work in the most convenient way,
   i.e., completion appending a / automatically, and
   the fileutils stripping off the / automatically.

The "most convenient way" as I see it is for the program to act as a
simple program which executes a simple system call.  

   Is there a practical problem that my suggested solution
   (of only stripping the / when the path is a directory)
   does not solve?

Yes.  If the file is changed from a directory to an ordinary file
between the stat and the rename, then the (new) file gets obliterated.
The original semantics guarantee (because they rely on the kernel to
make this decision) a certain measure of atomicity.

The general idea is that programs should not be more clever than the
kernel, thus, you get a system with only one set of rules to remember
instead of two.

	-mib