On Sun, Jun 25, 2017 at 11:16:00PM +0200, Ingo Schwarze wrote: > Hi, > > Paul de Weerd wrote on Sun, Jun 25, 2017 at 10:46:15PM +0200: > > On Sun, Jun 25, 2017 at 03:12:26PM +0200, Ingo Schwarze wrote: > > > | If you are really unsure, study the output of > > | $ find * > > | first, before typing > > | $ rm -rf * > > | No non-standard option is needed at all for this. > > > Very bad example. You study the output of find * and another process > > writes a new file in the mean time. With rm -v, you would've known. > > I don't buy the talk about race conditions at all. > > If other processes may be writing important files there, then for > god's sake don't rm -rf it. Besides, the rm -v output arrives too > late, when the data is already gone. > > If the directory is full of transient files and removing them is OK, > than it obviously doesn't matter what exactly got removed. > > Seriously, files not important enough to be kept, but so important > that you need an audit trail concerning their removal? That sounds > like a very unusual use case at best. > > > Landry's argument about the progress-meter has some merit, but it > is clearly more important for copying than for removing, and it is > clearly more important for copying over the network than for plain > cp(1), so i'm not sure it is sufficient justification.
scp -v? $ mkdir ../abc $ scp -v ./*pdf ../abc/ Executing: cp -- ./iso-prog_lang_C-WG14-N869.pdf ../abc/ Executing: cp -- ./iso-prog_lang_C.WG14-N897.pdf ../abc/ Executing: cp -- ./n1124.pdf ../abc/ Executing: cp -- ./n1256.pdf ../abc/ Executing: cp -- ./n1570.pdf ../abc/ ... $ scp -v n1570.pdf ../abc/single_file.pdf Executing: cp -- n1570.pdf ../abc/single_file.pdf -pk > Anyway, the whole thread looks awfully bikeshedish, so i guess > i should set a better example and shut up... > > Yours, > Ingo > > > P.S. > On the humorous side: > > Landry mentioned about rsync: > > > Technically it could be possible to replicate mv with rsync > > --remove-source-files ... :) > > Talk about the kitchen sink... > > And i heard rumours that some rsync(1) command line options > are so long that they don't fit into the command line length > limit of some shells. ;-) >
