Why does "cp -r a/. b" behave as it does?

Question

I thought that a and a/. is the same path. However, I've found that cp and rsync copy directory content instead of directory itself when /. is added to the source path. I also tried a/inner/..; this did the trick as well.

$ cp -r a b  # Copies dir a into dir b.
$ cp -r a/. b  # Copies files from dir a into dir b.
$ cp -r a/inner/.. b  # Also copies files from dir a into dir b.
$ cd a && cp -r . ../b  # One more way to copy inner files.

I understand that this is useful. But I'm a bit confused because it seems this feature breaks standards.

How does this work? Is this feature documented somewhere? Is this a feature of the OS, cp or bash?

Answer 1

I understand that this is useful. But I'm a bit confused because it seems this feature breaks standards.

cp behavior when copying recursively from a/. to b is perfectly consistent with its "normal" behavior.

By default, cp's doesn't create parent directories. This can be modified with the parents switch:

   --parents
          use full source file name under DIRECTORY

But what does that mean?

It means that while the command

cp --parents -r some/path/to/source dest

will copy the source directory's contents into dest/some/path/to/source, the command

cp -r some/path/to/source dest

will copy the source directory's contents into dest/source.

Likewise, the command

cp -r some/path/to/source/. dest

will copy the source directory's contents into dest/., which is just dest.

I thought a and a/. is the same path.

a and a/. is the same path. But as an argument to cp, it is just a string.

Note that the commands

cp --parents -r some/path/to/source dest

and

cd some/path/to && cp --parents -r source dest

will behave differently as well.

---

What about cp -r a/inner/.. b? Taking into account your explanation, should not it copy files to b/.. (i.e. to the current directory)?

Well, yes. This is an exception.

At least in the GNU version of cp, there is a special case for for the .. basename.

From coreutils-8.22/src/cp.c:

          if (parents_option)
            {
              [removed]
            }
          else
            {
              char *arg_base;
              /* Append the last component of 'arg' to 'target_directory'.  */

              ASSIGN_BASENAME_STRDUPA (arg_base, arg);
              /* For 'cp -R source/.. dest', don't copy into 'dest/..'. */
              dst_name = (STREQ (arg_base, "..")
                          ? xstrdup (target_directory)
                          : file_name_concat (target_directory, arg_base,
                                              NULL));
            }

The motivation seems to be to avoid copying outside the destination folder, which – while perfectly consistent with cp's behavior in every other case – is a little counterintuitive and could have unpleasant consequences.

After all, I don't think anybody would expect the command

cp -r .. ~

to affect files outside his home directory...

Answer 2

$ mkdir a b a/inner
$ touch a/a{1..3} b/b{1..3}
$ ls -R
.:
a  b

./a:
a1  a2  a3  inner

./a/inner:

./b:
b1  b2  b3
$ cp a b
cp: omitting directory ‘a’
$ cp a/. b
cp: omitting directory ‘a/.’
$ cp a/inner/.. b
cp: omitting directory ‘a/inner/..’
$ cd a && cp . ../b
cp: omitting directory ‘.’
$ cd ..
$ ls -R
.:
a  b

./a:
a1  a2  a3  inner

./a/inner:

./b:
b1  b2  b3

None of the things you say happen, actually happen. The four cp commands do nothing. Perhaps you have an alias for cp loaded. You can check this with alias cp.

Answer 3

Apropos rsync(1), read its manual carefully. It uses some unusual conventions to mean "the contents of the directory" vs "the directory and its contents."

For cp(1) and other Linux commands, at the kernel level a and a/. and even a/inner/.. refer to the exact same directory. That doesn't mean the application can't parse them for itself and give them funky different meanings, but it is easier to just ship the string to the kernel, who will do the right thing.

Answer 4

If I recall correctly I believe the . in this instance works similar to an *. In essence, a wildcard character.