GNU bug report logs - #16889
erratic behavior of cp command i.e while copying files (using *) from one directory to another directory

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 16889 in the body.
You can then email your comments to 16889 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Anil Kumar <linuxdeveloper7 <at> gmail.com>
To: bug-coreutils <at> gnu.org
Subject: erratic behavior of cp command i.e while copying files (using *) from
 one directory to another directory
Date: Wed, 26 Feb 2014 18:06:54 +0530

Hello

I have observed, one erratic behavior of cp command i.e while copying
files (using *) from one directory to another directory if
we miss destination directory then cp command copies content of 1st
file into 2nd file of same source directory instead of giving any
error.

Here is the scenario:

#ls -l
total 8
drwxr-xr-x 2 root root 4096 Feb 26 17:34 ddir
drwxr-xr-x 2 root root 4096 Feb 26 17:36 sdir


# echo "hello" > sdir/hello.txt
# echo "bye" > sdir/bye.txt

# cat sdir/hello.txt
hello

# cat sdir/bye.txt
bye

# cp sdir/*.txt

# cat sdir/hello.txt
bye

# cat sdir/bye.txt
bye

[Anil] Not sure, why "cp sdir/*.txt" command has copied data of
bye.txt into hello.txt ? I think, its not desired behavior.
 'cp' command should have produced error e.g destination is missing etc .

One more example of similar behavior:
# echo "hello" > sdir/hello.txt
# echo "bye" > sdir/bye.txt

# cat sdir/hello.txt
hello

# cat sdir/bye.txt
bye

# cp sdir/*

# cat sdir/hello.txt
bye

# cat sdir/bye.txt
bye

[Anil]Here again "bye" has been copied into hello.txt which is not
desired behavior.

Here is strace output command "strace  cp sdir/*"

stat("sdir/hello.txt", {st_mode=S_IFREG|0644, st_size=6, ...}) = 0
stat("sdir/bye.txt", {st_mode=S_IFREG|0644, st_size=4, ...}) = 0
stat("sdir/hello.txt", {st_mode=S_IFREG|0644, st_size=6, ...}) = 0
open("sdir/bye.txt", O_RDONLY)          = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=4, ...}) = 0
open("sdir/hello.txt", O_WRONLY|O_TRUNC) = 4
fstat(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
fadvise64(3, 0, 0, POSIX_FADV_SEQUENTIAL) = 0
read(3, "bye\n", 65536)                 = 4
write(4, "bye\n", 4)                    = 4
read(3, "", 65536)                      = 0
close(4)                                = 0
close(3)                                = 0
lseek(0, 0, SEEK_CUR)                   = -1 ESPIPE (Illegal seek)
close(0)                                = 0
close(1)                                = 0
close(2)                                = 0
exit_group(0)                           = ?

Message #8 received at 16889 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Anil Kumar <linuxdeveloper7 <at> gmail.com>
Cc: 16889 <at> debbugs.gnu.org
Subject: Re: bug#16889: erratic behavior of cp command i.e while copying files
 (using *) from one directory to another directory
Date: Wed, 26 Feb 2014 16:57:31 +0000

tag 16889 notabug
close 16889
stop

On 02/26/2014 12:36 PM, Anil Kumar wrote:
> Hello
> 
> I have observed, one erratic behavior of cp command i.e while copying
> files (using *) from one directory to another directory if
> we miss destination directory then cp command copies content of 1st
> file into 2nd file of same source directory instead of giving any
> error.
> 
> Here is the scenario:
> 
> #ls -l
> total 8
> drwxr-xr-x 2 root root 4096 Feb 26 17:34 ddir
> drwxr-xr-x 2 root root 4096 Feb 26 17:36 sdir
> 
> 
> # echo "hello" > sdir/hello.txt
> # echo "bye" > sdir/bye.txt
> 
> # cat sdir/hello.txt
> hello
> 
> # cat sdir/bye.txt
> bye
> 
> # cp sdir/*.txt
> 
> # cat sdir/hello.txt
> bye
> 
> # cat sdir/bye.txt
> bye
> 
> [Anil] Not sure, why "cp sdir/*.txt" command has copied data of
> bye.txt into hello.txt ? I think, its not desired behavior.
>  'cp' command should have produced error e.g destination is missing etc .
> 
> One more example of similar behavior:
> # echo "hello" > sdir/hello.txt
> # echo "bye" > sdir/bye.txt
> 
> # cat sdir/hello.txt
> hello
> 
> # cat sdir/bye.txt
> bye
> 
> # cp sdir/*
> 
> # cat sdir/hello.txt
> bye
> 
> # cat sdir/bye.txt
> bye
> 
> [Anil]Here again "bye" has been copied into hello.txt which is not
> desired behavior.

So cp doesn't expand the sdir/* itself.
The shell does that and just passes the separate arguments to cp.
This is a disadvantage of the globbing being done by the shell,
but there are advantages to.

thanks,
Pádraig.

Message #15 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Anil Kumar <linuxdeveloper7 <at> gmail.com>
To: bug-coreutils <at> gnu.org
Subject: Re: erratic behavior of cp command i.e while copying files (using *)
 from one directory to another directory
Date: Wed, 26 Feb 2014 18:11:30 +0530

Here is version info of cp command
=======
cp --version
cp (GNU coreutils) 8.20
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Torbjörn Granlund, David MacKenzie, and Jim Meyering.'




On Wed, Feb 26, 2014 at 6:06 PM, Anil Kumar <linuxdeveloper7 <at> gmail.com> wrote:
> Hello
>
> I have observed, one erratic behavior of cp command i.e while copying
> files (using *) from one directory to another directory if
> we miss destination directory then cp command copies content of 1st
> file into 2nd file of same source directory instead of giving any
> error.
>
> Here is the scenario:
>
> #ls -l
> total 8
> drwxr-xr-x 2 root root 4096 Feb 26 17:34 ddir
> drwxr-xr-x 2 root root 4096 Feb 26 17:36 sdir
>
>
> # echo "hello" > sdir/hello.txt
> # echo "bye" > sdir/bye.txt
>
> # cat sdir/hello.txt
> hello
>
> # cat sdir/bye.txt
> bye
>
> # cp sdir/*.txt
>
> # cat sdir/hello.txt
> bye
>
> # cat sdir/bye.txt
> bye
>
> [Anil] Not sure, why "cp sdir/*.txt" command has copied data of
> bye.txt into hello.txt ? I think, its not desired behavior.
>  'cp' command should have produced error e.g destination is missing etc .
>
> One more example of similar behavior:
> # echo "hello" > sdir/hello.txt
> # echo "bye" > sdir/bye.txt
>
> # cat sdir/hello.txt
> hello
>
> # cat sdir/bye.txt
> bye
>
> # cp sdir/*
>
> # cat sdir/hello.txt
> bye
>
> # cat sdir/bye.txt
> bye
>
> [Anil]Here again "bye" has been copied into hello.txt which is not
> desired behavior.
>
> Here is strace output command "strace  cp sdir/*"
>
> stat("sdir/hello.txt", {st_mode=S_IFREG|0644, st_size=6, ...}) = 0
> stat("sdir/bye.txt", {st_mode=S_IFREG|0644, st_size=4, ...}) = 0
> stat("sdir/hello.txt", {st_mode=S_IFREG|0644, st_size=6, ...}) = 0
> open("sdir/bye.txt", O_RDONLY)          = 3
> fstat(3, {st_mode=S_IFREG|0644, st_size=4, ...}) = 0
> open("sdir/hello.txt", O_WRONLY|O_TRUNC) = 4
> fstat(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
> fadvise64(3, 0, 0, POSIX_FADV_SEQUENTIAL) = 0
> read(3, "bye\n", 65536)                 = 4
> write(4, "bye\n", 4)                    = 4
> read(3, "", 65536)                      = 0
> close(4)                                = 0
> close(3)                                = 0
> lseek(0, 0, SEEK_CUR)                   = -1 ESPIPE (Illegal seek)
> close(0)                                = 0
> close(1)                                = 0
> close(2)                                = 0
> exit_group(0)                           = ?

Message #18 received at 16889 <at> debbugs.gnu.org (full text, mbox):

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Anil Kumar <linuxdeveloper7 <at> gmail.com>, 16889 <at> debbugs.gnu.org
Subject: Re: bug#16889: erratic behavior of cp command i.e while copying files
 (using *) from one directory to another directory
Date: Wed, 26 Feb 2014 18:10:54 +0100

tag 16889 notabug
close 16889
thanks

On 02/26/2014 01:36 PM, Anil Kumar wrote:
> I have observed, one erratic behavior of cp command i.e while copying
> files (using *) from one directory to another directory if
> we miss destination directory then cp command copies content of 1st
> file into 2nd file of same source directory instead of giving any
> error.

Thanks for the bug report, however, there's nothing we can
do about this in coreutils cp(1). See below.

> Here is the scenario:
>
> #ls -l
> total 8
> drwxr-xr-x 2 root root 4096 Feb 26 17:34 ddir
> drwxr-xr-x 2 root root 4096 Feb 26 17:36 sdir
>
>
> # echo "hello" > sdir/hello.txt
> # echo "bye" > sdir/bye.txt
>
> # cat sdir/hello.txt
> hello
>
> # cat sdir/bye.txt
> bye
>
> # cp sdir/*.txt
>
> # cat sdir/hello.txt
> bye
>
> # cat sdir/bye.txt
> bye

The point is that cp(1) does not even see the '*.txt' pattern.
Instead, the invoking shell substitutes the pattern and passes
the actual file names to 'cp'.
To get and idea what happens, you can put echo before 'cp':

  $ echo cp sdir/*.txt
  cp sdir/bye.txt sdir/hello.txt

Given the above command, cp detects that both files are regular
files, and therefore copies the content of sdir/bye.txt to
sdir/hello.txt.

BTW: this case is similar to the one explained in our FAQ:
http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#ls-_002da-_002a-does-not-list-dot-files

As this is desired behavior, I'm tagging this issue as not a bug,
and I'm marking it as done.
If there are still open points, feel free to continue the discussion.

Have a nice day,
Berny

Message #21 received at 16889 <at> debbugs.gnu.org (full text, mbox):

From: Bob Proulx <bob <at> proulx.com>
To: Anil Kumar <linuxdeveloper7 <at> gmail.com>
Cc: 16889 <at> debbugs.gnu.org
Subject: Re: bug#16889: erratic behavior of cp command i.e while copying
 files (using *) from one directory to another directory
Date: Wed, 26 Feb 2014 12:53:07 -0700

Anil Kumar wrote:
> I have observed, one erratic behavior of cp command i.e while copying
> files (using *) from one directory to another directory if
> we miss destination directory then cp command copies content of 1st
> file into 2nd file of same source directory instead of giving any
> error.

Others have already replied about this topic.  But I wanted to mention
the GNU extension -t, --target-directory=DIRECTORY option.  The
documentation says:

     ...
     cp [OPTION]... -t DIRECTORY SOURCE...

   * If the --target-directory (-t) option is given, or failing
     that if the last file is a directory and the
     --no-target-directory (-T) option is not given, cp copies
     each SOURCE file to the specified directory, using the SOURCEs
     names.

  -t DIRECTORY
  --target-directory=DIRECTORY
     Specify the destination DIRECTORY.  *Note Target directory::.

Using it can sometimes be useful at times to make commands simpler and
more clear about what is wanted.  This also allows the target
directory to be specified with the command and an unknown number of
files to follow on the command line.  This is most useful when using
commands such as 'find' and others.  The documentation goes into some
detail about using it that way.

I will include the entire "Target directory" section at the bottom for
further reference.

Bob

2.8 Target directory
====================

The `cp', `install', `ln', and `mv' commands normally treat the last
operand specially when it is a directory or a symbolic link to a
directory.  For example, `cp source dest' is equivalent to `cp source
dest/source' if `dest' is a directory.  Sometimes this behavior is not
exactly what is wanted, so these commands support the following options
to allow more fine-grained control:

`-T'
`--no-target-directory'
     Do not treat the last operand specially when it is a directory or a
     symbolic link to a directory.  This can help avoid race conditions
     in programs that operate in a shared area.  For example, when the
     command `mv /tmp/source /tmp/dest' succeeds, there is no guarantee
     that `/tmp/source' was renamed to `/tmp/dest': it could have been
     renamed to `/tmp/dest/source' instead, if some other process
     created `/tmp/dest' as a directory.  However, if `mv -T
     /tmp/source /tmp/dest' succeeds, there is no question that
     `/tmp/source' was renamed to `/tmp/dest'.

     In the opposite situation, where you want the last operand to be
     treated as a directory and want a diagnostic otherwise, you can use
     the `--target-directory' (`-t') option.

`-t DIRECTORY'
`--target-directory=DIRECTORY'
     Use DIRECTORY as the directory component of each destination file
     name.

     The interface for most programs is that after processing options
     and a finite (possibly zero) number of fixed-position arguments,
     the remaining argument list is either expected to be empty, or is
     a list of items (usually files) that will all be handled
     identically.  The `xargs' program is designed to work well with
     this convention.

     The commands in the `mv'-family are unusual in that they take a
     variable number of arguments with a special case at the _end_
     (namely, the target directory).  This makes it nontrivial to
     perform some operations, e.g., "move all files from here to
     ../d/", because `mv * ../d/' might exhaust the argument space, and
     `ls | xargs ...' doesn't have a clean way to specify an extra
     final argument for each invocation of the subject command.  (It
     can be done by going through a shell command, but that requires
     more human labor and brain power than it should.)

     The `--target-directory' (`-t') option allows the `cp', `install',
     `ln', and `mv' programs to be used conveniently with `xargs'.  For
     example, you can move the files from the current directory to a
     sibling directory, `d' like this:

          ls | xargs mv -t ../d --

     However, this doesn't move files whose names begin with `.'.  If
     you use the GNU `find' program, you can move those files too, with
     this command:

          find . -mindepth 1 -maxdepth 1 \
            | xargs mv -t ../d

     But both of the above approaches fail if there are no files in the
     current directory, or if any file has a name containing a blank or
     some other special characters.  The following example removes
     those limitations and requires both GNU `find' and GNU `xargs':

          find . -mindepth 1 -maxdepth 1 -print0 \
            | xargs --null --no-run-if-empty \
                mv -t ../d


The `--target-directory' (`-t') and `--no-target-directory' (`-T')
options cannot be combined.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.