Setting up travis was surprisingly easy
]]>good job !!
]]>It's just a rewrite in Python3
]]>Try with --ignore-errors ;-)
Whoa, I somehow totally missed that. Thanks.
]]>This is very nice!
Thanks, I appreciate it.
Any chance for it to handle errors that occur during the copying process, instead of just stopping?
I think what you need is already implemented.
Try with --ignore-errors ;-)
]]>I have a feature request: any chance for it to handle errors that occur during the copying process, instead of just stopping? For example, suppose I want to copy a bunch of files to a usb drive formatted FAT, but a few of the filenames have windows-illegal characters in them. In this scenario I'd like all the non-problematic files copied without my intervention, and then a list of error messages at the end saying which files failed to copy.
]]>But I guess it won't be very hard to implement. I'll have a look
]]>Right now, the main reason for this failing is that mv can just rename files if they reside on the same partition/mount point. mv'ing a 1 GB file to a subdirectory, for instance, only takes a fraction of a second. With pymv it takes forever.
Do you see any way for pymv *only* using pycp with delete_afterwards if the mv is not a rename, but actually has to copy over data to a different partition? That would be amazing.
]]>I'll try to fix the bugs before implementing new features
But that's a neat idea.
]]>This is cool man!
Anybody alias cp to pycp and mv to pymv already?
Still unsure to do that
I have although It'd be even better with support for the -u flag. From man cp:
-u, --update
copy only when the SOURCE file is newer than the destination file or when the destination file is missing
Anybody alias cp to pycp and mv to pymv already?
Still unsure to do that
]]>EDIT:
just to be sure: you're using pycp version 6.1, right?
The latest from the git
]]>Looks like we really have a bug here.
I don't lilke the behavior depending on wether or not you have a final '/' or whether or not you have subfolders.
And the goal (as the name implies) for pycp is to have exactly the same behavior as cp.
Still not sure where the bug really is.
I'll have a look maybe next week (sorry, quite busy here)
If you want this bug to be fixed quicker, you can always try and write a (failing) automatic test.
It's not that hard (well, if you no a little bit of Python, of course) and it would really help me fix it.
EDIT:
just to be sure: you're using pycp version 6.1, right?
[23:12:58] $ mkdir ~/testing/pycp-dir
$ pycp -sg /mnt/Documents/NR/ ~/testing/pycp-dir/
This has essentially done
cp /mnt/Documents/NR/* ~/testing/pycp-dir/
. In other words, it's dumped the contents of the SRC file into DEST instead of copying the folder over first and then it's contents
Edit: I can confirm the poster above: omitting the final "/" from the source dir it copies as expected
[23:13:48] $ pycp -sg /mnt/Documents/NR ~/testing/pycp-dir/
Also works with a dir containing no subfolders
]]>