Tag Info

Hot answers tagged

20

mv already supports this out of the box (at least in Debian): mv --backup=t <source_file> <dest_file> As seen in mv(1) manpage: --backup[=CONTROL] make a backup of each existing destination file The backup suffix is `~', unless set with --suffix or SIM‐ PLE_BACKUP_SUFFIX. The version control method may be selected via ...


16

In Bash (and some others), you can use brace expansion to accomplish this in one line: mv bar/{,.}* . The comma separates a null and a dot, so the mv command sees filenames that match * and .*


11

In order to avoid a useless use of cat (and if you don't use rsync): xargs -a file_list.txt mv -t /path/to/dest This will handle any valid filename, unless it contains a newline, if the files are listed one per line.


9

rsync has several options that can take a list of files to process(--files-from, --include-from, etc.).


8

Your command mv /* ../* has moved the entire filesystem (/) into /var/www/forum (../). You can try the reverse, i.e. move to /var/www/forum and run mv ./* / but you may as well accept that it is fatally broken. Restore from backups.


7

Use bash variables and a for loop: for i in *;do mv $i ${i%0000777};done when you surround the variable name with {} and add a % sign, it returns the value of the variable with everything after the % removed. If you use a # sign it will remove from the beginning of the string. so for i in *;do mv $i ${i#thumb_};done Would strip the thumb_ off the front.


6

This should do it: mv /directory_one/* /directory_one/.* /directory It will move regular files and dotfiles.


6

You are thinking about things from the wrong level, is all. If you move a file within the confines of a single ZFS dataset, it will react similarly to what you're expecting. If you move a file within the confines of a pool, but between datasets, it is a real move. Yes, technically the data just went from point A to point B and both points are on the same ...


5

find . -depth -print0 | xargs -0 rename -n '$_ = lc $_' Take out the -n flag once you're sure that it's doing what you want.


5

Yes, the process with the file open will be reading the file via an open file descriptor. The mv command just changes the associated directory entry.


5

for file in `cat listoffiles`; do mv "$file" /path/of/destination ; done assuming bash, plus listoffiles containing one file per line. My only objection to the rsync route is that the OP asks for a method of moving the files, not copying them. rsync has more flags than a royal wedding, so I'm sure it can be further modified to do that, but sometimes ...


5

This might be different depending on your shell, but assuming bash: for a in $(find /home -maxdepth 1 -type d); do mv $a/homedir/* $a/; rmdir $a/homedir; done Run the find command separately to verify the list is what you expect before you run the full command and remove the rmdir part if you want to keep the empty homedir in each folder.


4

Just so you fully understand what must have happened, if you ran mv /* ../* from /var/www/forum/newrelease/: You moved everything in / (/*) everything in /var/www/forum/ (../*) except for the alphabetically last subdirectory of /var/www/forum/ into the alphabetically last subdirectory of /var/www/forum/. Try echo mv /* ../* anywhere to help visualize ...


3

Most of the binaries depend/use on the libc library. To find out, you can use ldd /path/to/binary It seems that you need to boot another image or live CD. Then, you can mount the relevant partition (/usr if it is separated or /) and rename the file.


3

I'd argue for cp being the fastest, even if marginally so. Between drives, 'mv' should essentially amount to cp + rm (copy to destination, then delete from source). On the same filesystem, 'mv' doesn't actually copy the data, it just remaps the inode, so it is far faster than cp. Rsync will be slower than cp since, it still needs to copy the entire file - ...


3

When the source and destination are mounted on different partitions, cp and mv will perform about the same, since mv cannot optimize anything. rsync offers advantages when you are doing an incremental transfer (such as when doing a daily backup), or when the destination is very remote and/or communication is unreliable (such as over the Internet). rsync ...


3

This is more of a comment and a meta observation on the way this forum works, but I feel pretty strongly that it should be stated more loudly than if I just left a comment in rudedog's answer. This is also a comment directed more at people who may have a problem similar to David Dean's question, but not identical. It is easy to do a huge amount of damage ...


3

mv -v -f ${srcDir}${prefix}* -t $archiveDir in this case if you quote, * will be interpreted literally


3

Use the rename script. Assuming that they all end with "0000777": rename -nv 's,0000777$,,' * If the output is what you want remove the -n parameter to make it actually rename them.


3

I would write a script with these tools utilized: find -regex {you_will_write_the_regex} -type d ... awk "to_lowercase" mv {from_capital} {to_lowercase} And run them like: http://www.cyberciti.biz/faq/unix-linux-execute-command-using-ssh/ Pipe them all! ;)


3

I'd expect that command to leave you with a single folder under /home (the last one in dictionary order) with all of the other folders that were under /home (and ncdu) directly under there. Ah - that's what's happened - virtfs happens to be the last folder. Try going to /home/virtfs and just mv the folders back to their original location. Suggested ...


2

First thing to know about globbing --it's done by the shell, not the command. Check your shell's man page for all the details.


2

The easiest way to do this is to do it in two command, because * doesn't match .whatever cd /foo mv bar/* ./ mv bar/.??* ./ You do not want to use bar/.* which I found out while committing this mistake: rm -rf ./.* This is a BAD THING. Anyone want to guess why? ;-)


2

Try the following: cp -rf ./tmp/members/* ./ Following that, remove ./tmp/members if you don't want to keep a copy. mv doesn't "overwrite." Using relative paths is a bad habit and will be something that you will easily regret. I recommend using full paths whenever reasonable.


2

Are you sure? Maybe there are is a symlink and the destination path actually is a subfolder of the source path. Compare the output of readlink -e /home/admin/Downloads/folder1 and readlink -e /home/admin/MyLibrary/MyVideos/TV/folder1.


2

use autodie; rename($file, "$dir/$newname") If it fails to rename for any reason it'll die. If the file isn't there it obviously failed to rename and that will be caught as well.


2

If the other process keeps the file open the entire time, then yes it should be able to continue reading. Just like you can delete an open file, and processes that file open will still be able to read/write from the file, until it closes.


2

Just posting this in case someone else searches for this issue. Since at least AIX 5.3 IBM has provided the recovery shell recsh just for this issue. Check IBM Documentation. Example of use: recsh; cp -p libc.a.new /usr/lib/libc.a; exit


2

I don't agree with first answer: it seems it's possible. mv preserves mtime (modification time), but it changes ctime (change time). So it's should be possible to archieve this by doing find dir2 -ctime +30 -delete (or whatever other expression with ctime). PS: and don't forget to double-check your command by running it with -print instead of -delete :)


2

Unless you exceed the command-line length with the globs mv /home/*/* /home should work. Note if you have files in /home/user those will also be moved to /home.



Only top voted, non community-wiki answers of a minimum length are eligible