[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [coreutils] [PATCH] unexpand: support --in-place option
From: |
Pádraig Brady |
Subject: |
Re: [coreutils] [PATCH] unexpand: support --in-place option |
Date: |
Mon, 08 Nov 2010 11:37:38 +0000 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 |
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.