Tag Info

New answers tagged

17

Use rsync with the --partial option rsync -av --partial sourcedir user@desthost:/destinationdir The --partial will keep partially transferred files. When you resume the rsync transfer after a ssh broken connection, partially transferred files will start resuming from the point where the ssh connection was lost, and also successfully transferred files will ...


-1

In bash, (not tested) cd /path/to/source/directory for f in *.raw do cp $f /path/to/destination/directory done


2

Assuming the *frames directories are all in the same directory, you can do something like cd to/the/parent/of/the/frames/dirs mkdir all-my-raws cp *.frames/*.raw all-my-raws/ To avoid duplication of files you can replace cp with ln to just create a new link to the same data.


1

You can use find for this. find /path/to/directories -type f -name "*.raw" -exec cp {} /new/path \; If you want to move the files instead of copying them, replace cp with mv After moving the files you can remove empty directories with find /path/to/directories -type d -empty -exec rmdir {} \;


-1

My proposed solution: Collect list of all directories in a bash array. Something like dirs=($(ls *.frames)) This way you will have all the directory names in an array. Run a loop for the entire range with something like for i in ${$dirs[@]}; do...... Within the loop, create a new directory somewhere, & move all files from current directory to that ...


0

Going on a tangent here since you're asking about *.txt files, there's one slight benefit of using less, which is to use its pre-processing feature to "modify the way the contents of the file are displayed". A contrived example would be to output the contents of a compressed file to the output: less compressed.txt.gz > uncompressed.txt But of course, ...


6

The difference is that cp is far clearer to humans. That is one of the first things you should be optimizing for. Using less in this way is so obscure, it's not really obvious that it works unless you try it out. The other answer points out that it doesn't work - if your file contains certain characters, and you expect the command to work without user ...


2

The cp variant is faster because it doesn't dump f1.txt contents to the screen: $ time cp f1.txt f2.txt real 0m0.002s user 0m0.004s sys 0m0.000s $ rm f2.txt $ time less f1.txt > f2.txt real 0m0.009s user 0m0.004s sys 0m0.000s 0.002 for cp vs 0.009 for less. cp can save some mode bits of the original file while less creates ...


3

less has been designed as a pager (e.g .with next page functionlity) for text files. As such it is less optimized for copying files than say cp (which has been designed to copy data), and might have a considerable overhead, thus lacking in performance. For starters, cp won't ask you for confirmation when handling files that contain special (e.g. control) ...


0

Normally, a symbolic link is inert: it can store any sequence of bytes (except null bytes, and only up to a certain length). When creating a symbolic link, it is irrelevant whether the content happens to point to an existing file. It's only when accessing the symbolic link that the existence of the target matters. So what you're seeing on your VPS is ...


0

Found two ways: for file in /src/*.desktop.in; do file=${file%.in} if test -e "/dest/$(basename ${file})" then cp "/src/${file}.in" "/dest/${file}" fi done rsync and --existing: for file in /src/*.desktop.in; do rsync --dry-run --existing --verbose "/src/${file}" "/dest/${file%.in}" done


1

Assuming that with folder you mean directory and assuming you have no spaces or special characters in your file and directory names: svn st | ack '^M' | cut -b 8- | cpio -pdmv backup This is cpio in pass-through mode (-p). It takes a list of filenames to copy from stdin. -d allows it to create directories, -m preserves modification times and -v makes it ...


1

file.vdi is in all likelihood a sparse file. This is very common with virtual machine disk images: parts that have never been written to are left as holes in the file that don't consume space. You can confirm by checking whether the length of the original file matches its disk usage: ls -l file.vdi; du file.dvi I expect that ls -l will report 14GB (actual ...


0

What you have is basically as good as it gets. You can save a tiny bit of file name manipulation by changing to the directory where you're enumerating the files. It's a matter of readability, not performance. set -e cd /destination for file in *.desktop; do cp "/src/$file.in" "$file" done Don't forget to check for failures.


1

for file in /destination/*.desktop; do echo cp "/src/${file##*/}.in" "$file"; done If everything looks good, remove echo.


1

I don't think GNU cp has anything to help you if you want to see what it would do without acting. If you want to log the files that were modified, you can use the -v option: cp -puv DIRECTORYA/* DIRECTORYB >copy.log Instead of cp, you can use rsync, which is a lot more powerful and installed almost everywhere except for low-end embedded systems (and ...


-1

If you wanted to run cp foo*bar whatever, then run echo foo*bar whatever instead.


1

$ ssh-copy-id Usage: /usr/bin/ssh-copy-id [-h|-?|-n] [-i [identity_file]] [-p port] [[-o <ssh -o options>] ...] [user@]hostname So in your case simply use: $ ssh-copy-id -i ~/.ssh/id_rsa.pub -p 22001 user@192.168.0.1 Because of your usage of quotes, the -p 22001 part became part of the hostname which explains the error you got.



Top 50 recent answers are included