bug#47151: closed (Re: bug#47151: cp --recursive funky behaviour)

[Paul Eggert]

On 2/21/22 10:49, Tomas wrote:

> I found this, I am not sure whether it's the right specs.
>
> https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/

Yes, or more precisely for 'cp':

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/cp.html

> "2) f) The files in the directory source_file shall be copied to the directory 
> dest_file, taking the four steps (1 to 4)
> listed here with the files as source_files."
>
> Is this the relevant part? It seems to me that this would support copying src/a 
> and src/b (the files in the directory source_file) to dest/a and dest/b (copied 
> to the directory dest_file) rather than to dest/src/a and dest/src/b (which 
> would be copying the directory, not the files in the directory). But maybe I'm 
> missing a part of the spec or am interpreting it differently.

Yes, I think the part you're missing is below. Your first "cp -r src 
dest" uses the 3rd paragraph quoted below; your second "cp -r src dst" 
uses the 2nd paragraph.

=====

The third synopsis form is denoted by two or more operands where the -R 
option is specified. The cp utility shall copy each file in the file 
hierarchy rooted in each source_file to a destination path named as follows:

    If target exists and names an existing directory, the name of the 
corresponding destination path for each file in the file hierarchy shall 
be the concatenation of target, a single <slash> character if target did 
not end in a <slash>, and the pathname of the file relative to the 
directory containing source_file.

    If target does not exist and two operands are specified, the name 
of the corresponding destination path for source_file shall be target; 
the name of the corresponding destination path for all other files in 
the file hierarchy shall be the concatenation of target, a <slash> 
character, and the pathname of the file relative to source_file.

=====