cp

Nope, what you are experiencing is true Unix-like behavior. The behavior you are originally used to, is GNU's.
 
There hasn't been any major changes in the code from cp(1) for about 30 years I think, so no.
 
I would also like to note that rsync also uses this same behavior.
 
I just tested cp -R in OpenBSD and it has the normal behaviour. I would say FreeBSDs behaviour is new, and perhaps from GNU.

I used FreeBSD before and also SunOS, Solaris and linux a little, I do not remember this strange, annoying behaviour.
 
After doing further investigation, it seems there is no true Unix-like behavior for cp() in recursive form. Different platforms have various different approaches to handling an appending slash. However the common notion is that if the source destination is a symlink, the appending slash will NOT copy it as a symlink and therefore is discourage from real use. Same thing with mv(), it can have disastrous results.

EDIT: Sorry folks, yet another update. I need coffee...
 
it seems there is no true Unix-like behavior for cp in recursive form
Probably also because there are a few different "strains" of Unix. There's the obvious BSD one we all know and love. Another big one was System V. Plus a bunch of variants that used a combination of BSD and System V. And then there's GNU; the acronym should tell you enough; GNU's Not Unix.
 
What do you think is 'normal'? I consider the behavior on FreeBSD to be normal and everything else strange.

Normal: dir and dir/ represent the same directory and should be treated indifferently.

The problem with cp -R dir/ dir2 is: for doing cp -R dir dir2 I normally use shell completion, but then I must delete the slash, otherwise dir2 gets trashed.

FreeBSDs cp -R dir/ dir2 is not necessary, one just does cp -R dir/* dir2 and so is better: one explicitly writes what one wants.

I used before FreeBSD 4, and later began again using 11. Note that this strange behaviour is first documented in the man page of 5.4.

Just too much people spoiling FreeBSD with cool things. There are some things that 20 years ago were clearly better, for example the installer, now the loader is being spoiled with lua. Perhaps one day FreeBSD will be like a linux distribution.
 
dir and dir/ represent the same directory and should be treated indifferently.

POSIX disagrees with you when it comes to symlinks.

FreeBSDs cp -R dir/ dir2 is not necessary, one just does cp -R dir/* dir2 and so is better: one explicitly writes what one wants.

Actually I think the way FreeBSD handles this is pretty smart, when it comes to dealing with symlinks as a possibility. But in general it's discouraged to use cp -R dir/ dir2.

Perhaps one day FreeBSD will be like a linux distribution.

That is uncalled for, don't you think?
 
And also scp behaves as expected. And also Debian Linux. But rsync seems to be different.

It would be interesting to test a FreeBSD < 5.4.
 
Let's say we have a path /a/b and b is a symlink to a directory of a different path, say /c/d/e. When you de-reference the symlink by adding a slash, like /a/b/, and change the name, what should happen to e from /c/d/e?

Let's make the question more interesting. Let's say the cwd is /f/g. Do both of these commands have similar results?

mv /a/b/ foo

mv /a/b/ /a

What then happens e?
 
In this case no idea. I must try. In one system and the other.

Is /a/b/ treated exactly as it were /c/d/e? Or as /c/d/e/?
 
In this case no idea. I must try. In one system and the other.

Is /a/b/ treated exactly as it were /c/d/e? Or as /c/d/e/?

My guess is /c/d/e, but I would like you to compare between systems for the sake of knowledge.
 
OpenBSD:

(1) Renames the directory e to /f/g/foo

(2) "rename a/b/ to a/b/: Not a directory"

But I can move something else to /a/b/ as expected.
 
Interestingly enough... FreeBSD does (1) exactly as OpenBSD, but (2) doesn't error. In regards to (1), I thought it would be different for FreeBSD?
 
hruodr, I feel like I messed up. I thought FreeBSD's use of /a/b/, if b were a symlink, would do a wildcard move/copy of the files to where b points to. I now understand your frustration because I see a tiny inconsistency, so I don't know why the design decision to do /a/b/ as /a/b/* if b is a directory. Hopefully a FreeBSD veteran in the community could shed some light here.
 
From the text there I do not see a change of -R in this direction. Perhaps one has to compare the source of 5.3 and 5.4, or just install an old version. But I would need time for it. Is there no one running a real old BSD System?
 
Also, you want to consult cp(1).

Code:
-R     If source_file designates a directory, cp copies the directory and
       the entire subtree connected at that point. If the source_file
       ends in a /, the contents of the directory are copied rather than
       the directory itself. This option also causes symbolic links to be
       copied, rather than indirected through, and for cp to create spe-
       cial files rather than copying them as normal files. Created di-
       rectories have the same mode as the corresponding source directory,
       unmodified by the process' umask.

This behaviour is the same on macOS and we, the FreeBSD/macOS faction, expect it like this. I know macOS users count for Linux users as much as girly swots. However, I can’t care less.
 
Back
Top