bug#20603: Possible bug in cp

[Bob Proulx]

Chris Puttick wrote:
> The expansion & consequences of my typo understood! However, given the
> risks inherent in this edge case (directory only has 2 files in it)
> and the unlikelihood of someone wanting to change a directory
> containing 2 different files into a directory containing 2 identical
> but differently named files, it would be great if the cp command to
> check, when the source and destination directories are the same, the
> file count in that directory and issue a warning before continuing if
> the file count =2.

So I think you are telling me that if I were to do this:

  mkdir /tmp/junk
  touch /tmp/junk/file1 /tmp/junk/file2
  cp /tmp/junk/file1 /tmp/junk/file2

You are suggesting that the cp command above would fail in the above
situation?  I am sorry but that is much to specific of something to
single out as a special case in the code.  And it would fail in most
perfectly valid situations.  Like the above.  The above is perfectly
valid and should not fail.

Additionally I often do things like this for example:

  cp foo.conf foo.conf.bak
  edit foo.conf
  cp foo.conf.bak foo.conf

It would be wrong if the above were to fail.

Additionally what about this case:

  mkdir /tmp/junk && cd /tmp/junk
  touch one.txt two.txt
  touch README
  cp *.txt

The shell will expand "cp *.txt" to be "cp one.txt two.txt".  The file
count for the directory will be three and therefore the suggested
special case rule would not be triggered.

I daresay that the suggested special case rule would only very rarely
be triggered when it would help and would be a false positive for most
valid cases.

I am sorry that you had a bad experience with file glob expansion.
But so far the suggestions for improvement hasn't made a compelling
argument yet.

Bob