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. 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. ;-)
