GNU bug report logs -
#6353
cp and mv with single wild card argument acts as if multiple arguments were entered.
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 6353 in the body.
You can then email your comments to 6353 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
owner <at> debbugs.gnu.org, bug-coreutils <at> gnu.org
:
bug#6353
; Package
coreutils
.
(Fri, 04 Jun 2010 16:17:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Darwin Gregory <darwin.gregory <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-coreutils <at> gnu.org
.
(Fri, 04 Jun 2010 16:17:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I did a quick search of the archive, and didn't find this one, but there
seems to be a potential logical failure in the cp and mv commands. It may
be specific to an implementation, but I feel it is a critical issue.
I have tested this on Suse Enterprise 10.x and OpenSuse 11.x (the only
implementations I currently have access to).
If you execute "cp /path/*" the command expands the wildcard, and treats the
last file as the destination directory. If the last file in /path/ is not a
directory the command fails, but not with the appropriate error. However,
if the last file in the directory (or other wildcard expansion) is a
directory, it will copy all earlier files in the expansion to that
directory.
The same happens for mv. I did mv * in my home directory where the last
entry was a workspace subdirectory. It moved all of my files and
directories to my workspace subdirectory.
I feel this is an unacceptable outcome for a single argument that is a
wildcard, since whether it works or not is based on the arbitrary presence
or absence of a directory as the final element in the wildcard expansion.
It would be much better to fail with an error indicating "missing
destination file operand" as it does if the first argument does not
contain a wildcard.
Also, if a wildcard expansion contains exactly 2 elements, the second is
treated as a target whether or not it is a directory, causing a potential
overlay of data.
... Darwin
[Message part 2 (text/html, inline)]
Information forwarded
to
owner <at> debbugs.gnu.org, bug-coreutils <at> gnu.org
:
bug#6353
; Package
coreutils
.
(Fri, 04 Jun 2010 20:45:03 GMT)
Full text and
rfc822 format available.
Message #8 received at 6353 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 06/04/2010 10:13 AM, Darwin Gregory wrote:
> I did a quick search of the archive, and didn't find this one, but there
> seems to be a potential logical failure in the cp and mv commands. It may
> be specific to an implementation, but I feel it is a critical issue.
It is generic to how Unix works. Basically, globs are expanded by the
shell, prior to the command itself being executed.
> If you execute "cp /path/*" the command expands the wildcard, and treats the
> last file as the destination directory.
As it has always done historically, and was standardized by POSIX.
> If the last file in /path/ is not a
> directory the command fails, but not with the appropriate error. However,
> if the last file in the directory (or other wildcard expansion) is a
> directory, it will copy all earlier files in the expansion to that
> directory.
Yep.
> I feel this is an unacceptable outcome for a single argument that is a
> wildcard, since whether it works or not is based on the arbitrary presence
> or absence of a directory as the final element in the wildcard expansion.
But mv has no idea whether you typed a glob or spelled it out on the
command line.
> It would be much better to fail with an error indicating "missing
> destination file operand" as it does if the first argument does not
> contain a wildcard.
How? That information is lost by the shell's glob expansion before ls
even starts executing.
>
> Also, if a wildcard expansion contains exactly 2 elements, the second is
> treated as a target whether or not it is a directory, causing a potential
> overlay of data.
This behavior is required by POSIX, but you can use an alias or shell
function to instead invoke mv -i or cp -i by default, which will catch
common errors like this.
For more information on globbing, see this FAQ:
http://www.gnu.org/software/coreutils/faq/#expr-2-_002a-3-does-not-work
--
Eric Blake eblake <at> redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
owner <at> debbugs.gnu.org, bug-coreutils <at> gnu.org
:
bug#6353
; Package
coreutils
.
(Fri, 04 Jun 2010 20:45:03 GMT)
Full text and
rfc822 format available.
Message #11 received at 6353 <at> debbugs.gnu.org (full text, mbox):
If you execute "cp /path/*" the command expands the wildcard, and
treats the last file as the destination directory.
That is at it should be, * is expanded by the shell, not by the command.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-coreutils <at> gnu.org
:
bug#6353
; Package
coreutils
.
(Fri, 04 Jun 2010 20:53:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 6353 <at> debbugs.gnu.org (full text, mbox):
Darwin Gregory wrote:
> I did a quick search of the archive, and didn't find this one,
It gets discussed every so often. Look for file glob or file
globbing.
> but there seems to be a potential logical failure in the cp and mv
> commands. It may be specific to an implementation, but I feel it is
> a critical issue.
This applies to *all* command line use of shell wildcards. It isn't
specific to GNU or GNU coreutils or any other particular command.
This is part of the fabric that underlays the entire operating system.
> If you execute "cp /path/*" the command expands the wildcard, and treats the
> last file as the destination directory. If the last file in /path/ is not a
> directory the command fails, but not with the appropriate error. However,
> if the last file in the directory (or other wildcard expansion) is a
> directory, it will copy all earlier files in the expansion to that
> directory.
The part that you are missing is that the shell expands '*' file glob
characters prior to passing the result as arguments to the command.
The command invoked does not receive the '*' itself (unless there were
no matches at all) and the command cannot tell the difference between
the user specifying files explicitly versus having had a file glob
expanded.
> The same happens for mv. I did mv * in my home directory where the last
> entry was a workspace subdirectory. It moved all of my files and
> directories to my workspace subdirectory.
Yes. That is forty years of expected behavior. Shell wildcards are
expanded by the shell before invoking the command.
> I feel this is an unacceptable outcome for a single argument that is a
> wildcard, since whether it works or not is based on the arbitrary presence
> or absence of a directory as the final element in the wildcard expansion.
This is a fundamental behavior of the shell. The Unix philosophy is
to separate this behavior out into the shell so that it would be
applied uniformly to all commands.
Now you may say that this is unacceptable and be shocked by this but
if you think about the fact that this has been the standard behavior
for four decades then you must realize that there is some value and
benefit to this design or it would have been changed and replaced with
something different by now.
> It would be much better to fail with an error indicating "missing
> destination file operand" as it does if the first argument does not
> contain a wildcard.
This is not possible in the Unix command line shell architecture.
> Also, if a wildcard expansion contains exactly 2 elements, the second is
> treated as a target whether or not it is a directory, causing a potential
> overlay of data.
That is correct. Don't do that.
Note that you are always free to use a different shell that behaves
differently. There isn't any requirement that you use bash, or
whatever shell you happen to be using at the moment. It just turns
out that it is more useful than any of the alternatives. It is so
much more useful that you may find it difficult to locate successful
alternatives that do not do file glob expansion. And also you would
need to use a set of utilities that were designed to match the
behavior.
Bob
Information forwarded
to
owner <at> debbugs.gnu.org, bug-coreutils <at> gnu.org
:
bug#6353
; Package
coreutils
.
(Fri, 04 Jun 2010 21:05:01 GMT)
Full text and
rfc822 format available.
Message #17 received at submit <at> debbugs.gnu.org (full text, mbox):
On Friday 04 June 2010, Darwin Gregory wrote:
> If you execute "cp /path/*" the command expands the wildcard, and treats
> the last file as the destination directory. If the last file in /path/ is
> not a directory the command fails, but not with the appropriate error.
> However, if the last file in the directory (or other wildcard expansion)
> is a directory, it will copy all earlier files in the expansion to that
> directory.
>
> The same happens for mv. I did mv * in my home directory where the last
> entry was a workspace subdirectory. It moved all of my files and
> directories to my workspace subdirectory.
>
> I feel this is an unacceptable outcome for a single argument that is a
> wildcard, since whether it works or not is based on the arbitrary presence
> or absence of a directory as the final element in the wildcard expansion.
> It would be much better to fail with an error indicating "missing
> destination file operand" as it does if the first argument does not
> contain a wildcard.
>
> Also, if a wildcard expansion contains exactly 2 elements, the second is
> treated as a target whether or not it is a directory, causing a potential
> overlay of data.
cp and mv have no fault. It's the shell that expends the wildcard, so cp and
mv do not even see it; they just think they've been invoked with multiple
arguments, and behave as expected.
--
D.
Reply sent
to
Bob Proulx <bob <at> proulx.com>
:
You have taken responsibility.
(Mon, 07 Jun 2010 22:51:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Darwin Gregory <darwin.gregory <at> gmail.com>
:
bug acknowledged by developer.
(Mon, 07 Jun 2010 22:51:02 GMT)
Full text and
rfc822 format available.
Message #22 received at 6353-done <at> debbugs.gnu.org (full text, mbox):
Hi Darwin,
I am happy that you are satisfied with the responses. I am going to
close the bug ticket in the bug tracking system with this message.
Bob
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Tue, 06 Jul 2010 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 14 years and 356 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.