Xref: utzoo comp.unix.wizards:11555 comp.bugs.4bsd:1046
Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!amdcad!ames!mailrus!tut.cis.ohio-state.edu!bloom-beacon!mit-eddie!bbn!bbn.com!mesard
From: mesard@bbn.com (Wayne Mesard)
Newsgroups: comp.unix.wizards,comp.bugs.4bsd
Subject: Re: directory copying with cp; broken?
Message-ID: <30506@bbn.COM>
Date: 5 Oct 88 14:36:30 GMT
References: <40@ausonics.OZ>
Sender: news@bbn.COM
Followup-To: comp.unix.wizards
Lines: 33

Note Followup-To.

From article <40@ausonics.OZ>, by greyham@ausonics.OZ (Greyham Stoney):
> in article <8540@smoke.ARPA>, gwyn@smoke.ARPA (Doug Gwyn ) says:
>> "cp" is not changing anything; it's making a copy of the contents of a
>> file.  It wouldn't be safe for that to be turned into an actual
>> directory since at least the "." entry in it would be incorrect.
> 
> Minor semantic point. Come on, you know what I was getting at. No, I wasn't
> proposing it should create a directory, but rather that it made more sense to
> reject the copy (or just copy the directory contents and do away with the -r
> flag). Just depends on how you look at it I guess.
> 				Greyham

Indeed.  And more generally, a consistent way of handling directories
(i.e. directory files) needs to be established.  In SunOS 3.4:

  cp <dir> <fn>             ==>  "cp: <dir>: Is a directory (not copied).
  head, tail, cat <dir>     ==>  {works}
  more <dir>                ==>  "*** <dir>: directory ***"

My preference is for cp to do the right thing (i.e, nix the -r flag) and
for cat, head and tail (and any other file display* programs) to behave
as more(1) does, with the addition of a new option to cat(1) to
explicitly tell it to treat a directory as an ordinary file.

But that's just one opinion.

* It would be silly to remove functionality from file _processing_
  programs such as wc.

-- 
void *Wayne_Mesard();         MESARD@BBN.COM         BBN, Cambridge, MA