Re: [9fans] files vs. directories

[dexen deVries <dexen.devries@gmail.com>]

On Thursday 03 of February 2011 19:42:39 smiley@zenzebra.mv.com wrote:
> dexen deVries <dexen.devries@gmail.com> writes:
> >> oh yes, maintaining the usual semantics for cp becomes tricky.
> >>
> >> mkdir z
> >> cp x.c z
> >>
> >> do i mean to write x.c to z itself, or to a new file within z?
> >
> > nb., with the current semantics you *could* say `cp x.c z/' to be
> > unambiguous you want to create a child of `z', but it seems to be common
> > not to use trailing slash unless 100% necessary.
>
> dexen hits the nail on the head right there... files and directories
> could be contextually distinguished from each other by always specifying
> the directory name with a trailing "/".
>
> "foo.c/" means the directory foo.c/.
>
> "foo.c"  means the file ./foo.c
>
> There's no way that I know of to possibly interperet a path ending in
> "/" as a file (with the exception of reading raw Dir data, as on Plan
> 9 or "cat /" on, what was it, Solaris?).


I refuse to be signed under that idea. Really, I hate that idea.

The trailing slash could only be for cp(1)'s interpretation of second argument
-- it literally could mean, ``append the first argument's last component''. To
have it a system-wide policy is overkill. It's only the small optimization
done by cp(1) -- that is, it automagically appends first argument's last
component to the last argument -- that makes this distinction sensible in some
cases.

tl;dr version:
Hell no.

--
dexen deVries

``One can't proceed from the informal to the formal by formal means.''