Re: [PATCH] in place option for unexpand

[Sami Kerola]

On Sun, Mar 22, 2009 at 10:58, Jim Meyering <address@hidden> wrote:
> Sami Kerola wrote:
>
>> On Sun, Mar 22, 2009 at 08:22, Jim Meyering <address@hidden> wrote:
>>> Pádraig Brady wrote:
>>>> Sami Kerola wrote:
>>>>> Good weekend,
>>>>>
>>>>> If you consider in-line option is useful for unexpand I could wrote
>>>>> another patch for expand command which will do the same thing.
>>>>
>>>> Thanks for this. I'm wondering about usefulness to other coreutils.
>>>> Perhaps fmt,fold,nl,tac,tr would also benefit in addition to expand & 
>>>> unexpand?
>>
>> I think it sounds good idea that there are functions in coreutils lib
>> which implement the in-place. Unfortunately I am not good enough
>> programmer to come up with a routine that fits for all of the coreutil
>> programs. IMHO Making one command work right, converting the
>> functionality to general routine and monify rest of the commands is
>> right aproach.
>
> We prefer not to modify many programs, when adding
> a single new helper program can produce the same result.
> The Unix Philosophy...
>
> ...
>>>> BTW, I like the way you use $TMPDIR etc. contrary to the `sed` --in-place
>>>> option which uses a tmp file in the same dir as the original.
>>>> Using the same dir will fail in the case you've a file in a readonly dir
>>>> bind mounted to a writeable location for example.
>>>> On the otherhand it requires more code to support. For example
>>>> I think your rename() will fail if $TMPDIR is on
>>>> a different filesystem to the original file?
>>>
>>> Yes.  That is a disadvantage of using $TMPDIR.
>>
>> And that will be fixed ones copy is approach in use. Then I just need
>> remember to unlink leftover file.
>
> It's better (atomic) to use rename, and hence a temporary
> file on the same partition as the file in question.
> IMHO, requiring that the containing directory be writable is
> not a problem.

Updates.

License conditions are under work. Initial contact with GNU boston
office is done and my boss is figuring out how to get this sort of
paper work done.

Mean while I've continued with a first patch. I am having a hard time
with cp_option_init. My source file is created by mkstemp which causes
permissions to be 600. What ever I do with preserve permissions bits I
always seem to get source file permissions in place. Am I such an
amateur that I am not seeing something obvious, or is it really so
that there is no preserve destination permissions?

I also gave a thought to that general wrapper. By waving hands it
should be a tool that can handle 1. writes after pipe and 2. xargs
style in-placement. My work name for the command is writeafter. The
two usage cases in my theory should look something like this.

1. grep 127.0.0.1 /etc/hosts |
writeafter /etc/hosts

2. echo /etc/passwd /etc/shadow |
writeafter -I '{}' grep root '{}'

Does that sound like something reasonable? If yes, it might take a
while to come up with a well working implementation but I'm sure
that's doable.

-- 
   Sami Kerola
   http://www.iki.fi/kerolasa/