0

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?

| |
  • 5
    It only has one downvote and one person commenting on it (besides you), so "some folks" seems like too small a group to really worry about – Michael Mrozek Jul 27 '17 at 20:48
  • 2
    I would point out that sed /e is a gnu extension, and include the explanation inline with the answer instead of as a comment. – Jeff Schaller Jul 27 '17 at 21:14
3

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 -print0 and sed's -z) that weren't explicitly part of the OP's environment
  • obfuscation of the actual change, inside sed with the /e
  • 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 echo or printf.

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.

| |

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .