coreutils
[Top][All Lists]
Advanced

[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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]