On 07/11/10 20:17, Sami Kerola wrote: > I proposed in place editing support earlier (21 Mar 2009), but then > you could not accept the patch because (a) I had not done legal > paperwork (b) it was not awesome. Now legal matters should no longer > be issue, but quite frankly the point b could still be a problem. > > Last time I got few instructions how the in place could be better. So > here is the new version, that uses conventions of other commands; > like SIMPLE_BACKUP_SUFFIX & VERSION_CONTROL. Even without making in > place working with fmt, fold, nl, tac, tr & expand the patch is > pretty large, and potentially causes flock of bugs. > > There is also issue with permission bits when combined with backups. > To fix that copy.c requires some sort of, small or big, change, and I > don't feel good doing such before talking to maintainer first. > > I am afraid Pádraig was right last time; '[...] On the other hand > it's simple enough to achieve this using existing commands'. How > about you, now when it's more visible what's required when in place > uses copy.c etc. Is it time to document this change to rejected ideas > area, and never propose this again? Or keep on hacking to this > direction?
I was working on an inplace script/command to handle this. I was calling it `rp` in the attached, but thats a bit obtuse I think. http://lists.gnu.org/archive/html/bug-coreutils/2010-03/msg00261.html To me this is more "unixy" than adding the option to every filter. cheers, Pádraig.
