bug-cppi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug-cppi] Re: [PATCH] Add new option --in-place


From: Pádraig Brady
Subject: [bug-cppi] Re: [PATCH] Add new option --in-place
Date: Mon, 22 Mar 2010 03:26:20 +0000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3

On 21/03/10 11:14, Jim Meyering wrote:
> Pádraig Brady wrote:
> 
>> On 20/03/10 08:32, Jim Meyering wrote:
>>> Hello,
>>>
>>> [Cc'ing bug-coreutils...]
>>>
>>> Giuseppe proposed to add the --in-place option to GNU cppi,
>>> (cppi is a small program that can act as a filter
>>>   http://savannah.gnu.org/forum/forum.php?forum_id=6210
>>> but cppi is so small that adding even that single, relatively
>>> simple option would make it substantially more complicated.
>>>
>>> I'm nearly certain I've seen a program (possibly a small
>>> perl script) that can effectively add the --in-place
>>> functionality to any filter program, but so far my searches
>>> have been in vain.
>>>
>>> I want a tool that works like this:
>>>
>>>     in-place [--backup] 'cppi ...options' *.c
>>>
>>> For each .c file, it would apply the filter program, and upon each
>>> successful exit, it would update the .c file in place (atomically,
>>> of course) with the output from the filter.
>>>
>>> Can anyone point to existing code that does that?
>>
>> Well we were talking about a small "replace" or "inplace" script,
>> in coreutils/contrib/ which would use the facilities of various coreutils
>> http://lists.gnu.org/archive/html/bug-coreutils/2009-09/msg00327.html
>> I didn't get any feedback on the new cp --attributes-only option
>> though so was worried about adding this new interface.
> 
> Sorry I didn't reply.
> Your --attributes-only option looks worthwhile.

You had already expressed support for the idea in the thread,
and the patch is trivial.  I was more worried about not having
noticed other requests for this feature, which is now moot.

> However, I think the default behavior of an
> update-via-filter-and-replace program should use
> the temp-file-in-same-directory-and-rename technique
> rather than the non-atomic alternative.

Right. So the logic would be something like:

tf2=$(mktemp)
cleanup() { rm -f "$tf2"; } #TODO: tf1
trap "cleanup" EXIT
for file in *.whatever; do
  dir=$(dirname "$file")
  tf1=$(mktemp --tmpdir="$dir")
  if cp --attr "$file" "$tf1"; then
    # "$file" updated atomically
    # Should we `chmod u+rw` here to allow updating non rw files?
    $filter "$file" > "$tf1" &&
    mv "$tf1" "$file" #rename
  else
    # Note we don't use mv to unlink/copy as
    # /tmp might not support all attrs.
    # Also can't unlink in unwriteable dir.
    # Note won't be able to update non rw files here
    $filter "$file" > "$tf2" &&
    cp "$tf2" "$file" #truncate + copy
  fi
  rm -f "$tf1"
done

> The case in which the destination directory is
> unwritable is far less common, so if we support that
> at all, it should be only as a fallback, or perhaps
> only if some option is specified.

Auto fallback would be most appropriate I think.

cheers,
Pádraig.




reply via email to

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