4 ms·
> However, some users didn't like having to think about whether the source and destination were on the same mountpoint That's actually a good thing, because it
by adwn 11y ago
> However, some users didn't like having to think about whether the source and destination were on the same mountpoint
That's actually a good thing, because it makes scripts more composable. Imagine you wrote a script that contains a buried mv somewhere in it, then you'd have to document this restriction all the way up to the end users of your script. If the mv command doesn't handle the mount-point-spanning case, then this functionality will have to be repeated in all scripts that use mv (which would be a disaster).
> the great many naive users celebrated the change
That's a very arrogant, unwarranted thing to say.
- LukeShu 11y agoI didn't say it was a bad change. But, even good changes should make one frown at the groing complexity.
- adwn 11y ago> frown at the groing complexity When I have the chance to remove replicated complexity from a myriad of places and to concentrate it on one central point (and make the interface simpler and more consistent in the process), I don't frown, I laugh with joy.
- LukeShu 11y agoBut for more than a decade, it was a bug that moving across devices screwed up ownership. So then you still have to to be aware of whether you are moving across devices, but now if you are but don't realize it, it automatically screws up your data.
- jstimpfle 11y ago> > However, some users didn't like having to think about whether the source and destination were on the same mountpoint > That's actually a good thing, because it makes scripts more composable. I argue that it actually precludes any form of composability: http://jstimpfle.de/fun/composability.html http://jstimpfle.de/fun/composability.html