[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Add new option --in-place
From: |
Pádraig Brady |
Subject: |
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.
- Re: [PATCH] Add new option --in-place, Jim Meyering, 2010/03/20
- Re: [PATCH] Add new option --in-place, Pádraig Brady, 2010/03/20
- Re: [PATCH] Add new option --in-place, Jim Meyering, 2010/03/21
- Re: [PATCH] Add new option --in-place,
Pádraig Brady <=
- Re: [PATCH] Add new option --in-place, Pádraig Brady, 2010/03/22
- Re: [PATCH] Add new option --in-place, Pádraig Brady, 2010/03/22
- Re: [PATCH] Add new option --in-place, Eric Blake, 2010/03/22
- Re: [PATCH] Add new option --in-place, Pádraig Brady, 2010/03/22
- Re: [PATCH] Add new option --in-place, Jim Meyering, 2010/03/23
- Re: [PATCH] Add new option --in-place, Pádraig Brady, 2010/03/23
- Re: [PATCH] Add new option --in-place, Pádraig Brady, 2010/03/24
- Re: [PATCH] Add new option --in-place, Pádraig Brady, 2010/03/25