On Thursday 03 of February 2011 19:42:39 smi...@zenzebra.mv.com wrote: > dexen deVries <dexen.devr...@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.''
