greyham@ausonics.OZ (Greyham Stoney) (09/16/88)
No doubt people have noticed this before, but to my way of thinking [and this may well be the problem :-] cp on our BSD 4.2 system seems to be braindamaged. When both the source and destination are directories, and the -r option is not specified, the destination directory is left with a *file* by the name of the source directory. Much the same as if cp sourcedir destdir was really doing: cat sourcedir > destdir/sourcedir I would have though cp intelligent enough to realise that source and dest were directorys, and either do what the -r option does (so why do we need it?) or just reject the copy. (depending on how you view these types of things) Which ever solution, surely changing a directory into a regular file is a bit inconsistent?. greyham@ausonics.oz -- # Greyham Stoney: (disclaimer not necessary: I'm obviously irresponsible) # greyham@ausonics.oz - Ausonics Pty Ltd, Lane Cove. | greyham@utscsd.oz - # ^^^^^^^ (Official Sponsor of this message.) | Uni of Technology, Syd. # [.signature changed to celebrate NEW LOGNAME!! ] | Good Time City!!!
henry@utzoo.uucp (Henry Spencer) (09/21/88)
We long ago changed cp to reject an attempt to copy a directory. We've never been sorry. -- NASA is into artificial | Henry Spencer at U of Toronto Zoology stupidity. - Jerry Pournelle | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
gwyn@smoke.ARPA (Doug Gwyn ) (09/21/88)
In article <35@ausonics.OZ> greyham@ausonics.OZ (Greyham Stoney) writes: >... surely changing a directory into a regular file is a bit inconsistent?. "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.
greyham@ausonics.OZ (Greyham Stoney) (09/28/88)
in article <8540@smoke.ARPA>, gwyn@smoke.ARPA (Doug Gwyn ) says: > > In article <35@ausonics.OZ> greyham@ausonics.OZ (Greyham Stoney) writes: >>... surely changing a directory into a regular file is a bit inconsistent?. > > "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 -- # Greyham Stoney: (disclaimer not necessary: I'm obviously irresponsible) # greyham@ausonics.oz - Ausonics Pty Ltd, Lane Cove. | greyham@utscsd.oz - # ^^^^^^^ (Official Sponsor of this message.) | Uni of Technology, Syd. # [.signature changed to celebrate NEW LOGNAME!! ] | (what can I say...)
mesard@bbn.com (Wayne Mesard) (10/05/88)
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