So this answer seems to be especially scary to some folks. Now it is not the only answer I have given that has a negative score (it happens, along with a bunch that have no score), there are five others. Now I will stand by all the answers I have posted that have a negative score, but I think in this case my answer is the better (more unixish answer). I do not think Wildcard's answer is wrong, I voted it up, but it neglects the true power of unix which is using multiple tools to accomplish more than each can on its own. What would be the best way to convince people that this is a viable answer?
What Mr. Mrozek said; it's only one downvote. You may or may not find someone else that thinks the same way you do. I think you've done the right thing to add an explanation so people have a better chance of following along. You yourself note that 'sed eval is always risky'! Your answer adds:
- a rarer printf format, %U
- reliance on GNU tools (find's
-z) that weren't explicitly part of the OP's environment
- obfuscation of the actual change, inside
- requiring a confident parsing of the sed command to piece together the actual execution
I would also add that your Answer doesn't provide an easy way to do a "dry run" to make sure you got everything right before letting it loose on 10 Tb.
In contrast, Wildcard's answer uses only
find with its common
-exec option, and the
chown command, all of which are POSIX-specified. The desired changes are tied directly to each other; any more pair-wise changes could be added in very easily, and the whole thing could be easily tested by inserting an
At the end of the day, only the OP has this particular problem to solve, so we're not likely to get a lot of other readers with the same question; and it seems unlikely that we'll get a speed/performance comparison.
I admire the effort you put into the answer to make it robust and desire to demonstrate the effects of caching.