mv insane behavior

B

bentek

This is not a question. I noted the move command
mv ../../xxx.txt *
deletes xxx.txt and all files in current directory. Don't think a good thing. :(
 
It did what you told it to do, nothing else. '*' is expanded to the list of files/directories (try echo *), and it just so happened that the last entry was a directory (otherwise mv would fail). So the files are not "deleted", rather were moved to one of the directories you had in your current working directory.
 
yuripv79 said:
It did what you told it to do, nothing else. '*' is expanded to the list of files/directories (try echo *), and it just so happened that the last entry was a directory (otherwise mv would fail). So the files are not "deleted", rather were moved to one of the directories you had in your current working directory.
Click to expand...
I didn't know. Found all.
 
bentek said:
This is not a question. I noted the move command
mv ../../xxx.txt *
deletes xxx.txt and all files in current directory. Don't think a good thing. :(
Click to expand...
Look, this here is UNIX. UNIX is based on the "you get what you've asked for" principle, it is your sole responsibility to know what you're doing. If you want that mv holds your hand, add something like -iv as parameter.
 
I got these aliases to save me from fumble finger surprises:

Code: 
alias mkdir="mkdir -p -v"
alias cp="cp -ivp"
alias mv="mv -iv"
alias rm="rm -iv"
alias chmod="chmod -v"
alias chown="chown -v"
If I do a mistake at least I can see what has happened.
 
What you're pointing out here is probably the single worst design flat in Unix: The fact that utilities that handle files, and that know how to perform globbing, can not access the raw command line; and the fact that as far as argument processing is concerned, all command line arguments are treated the same, whether they are interpreted as switches (like -i or -f), or as arguments.

Matter-of-fact, about 1/3 of the "Unix haters handbook" is about this topic. And it is probably the biggest source of frustration for new GUI users (until they start writing shell scripts, when quoting becomes the worst one).

Imagine a directory with four files, called cunningly "-Rf", a, b and c/. (b is a subdirectory, the others are files). What should "rm -i *" do? Intuitively, it should ask the user three times, whether they want to delete the three files, and give one error message that you can't delete a directory using rm, you need to use rmdir. Instead it will delete a, b, and c, including all files in subdirectories of c. What should "mv *" do? Give an error message that mv needs two or more arguments, and that if it has more than 2, the last one must be a directory. Instead (and this is the case you found), it will move all the files into the subdirectory c. If there is already something called c/a, it will give unintelligible error messages. You can construct many more interestingly bizarre such cases.

All this could be fixed. It would require redefining how shells call programs (the "int main(int argc, char* argv[])" would need to change). And then there would need to be a sane library for parsing command-line switches or options versus arguments or parameters. Other operating systems (such as VMS) had all that, but Unix wasn't really designed; it was a research prototype that leaked out too soon, and now (50 years later) this is too late to fix.

In the meantime, all CLI Unix users need to understand how globbing works.
 
the shell expands * do everything in cwd (excluding dotfiles) in alphabetically order
if the last argument is not a directory (and there are more than 2 arguments) mv will fail
if the last arg is a directory then all the previous args (files dirs etc) will be moved into it

Code: 
host:test titus$ touch 1 2 3 4
host:test titus$ mv *
usage: mv [-f | -i | -n] [-v] source target
       mv [-f | -i | -n] [-v] source ... directory
host:test titus$ mkdir z
host:test titus$ mv *
host:test titus$ ls z
1       2       3       4
 
You must log in or register to reply here.
Back
Top