Re: [PATCH] in place option for unexpand

[Jim Meyering]

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?
> On the other hand it's simple enough to achieve this using existing commands:
>
> tf=$(mktemp)
> cleanup() { rm -f "$tf"; }
> trap "cleanup" EXIT
> for file in *.whatever; do
>     touch --reference="$file" "$tf"
>     chmod --reference="$file" "$tf"
>     unexpand "$file" > "$tf" &&
>     mv "$tf" "$file"
> done
>
> That as well as being more flexible will also give you
> auto cleanup of the temp file on Ctrl-C for example.
> You would have to add signal handling to your patch to do that.
> So what do people think about bringing the above logic
> internal to certain utils?

Another advantage of the more general approach is that
you automatically gain control of the backup-file policy,
through the VERSION_CONTROL envvar that GNU mv honors.

Rather than modifying each tool, how about a script
(or eventually a program written in C) along the lines of the above?
Then that program could be applied to any tool that acts as a filter.
You'd have to tell it two things: the command to run and the name of
the input file (contents to be replaced with output, upon success).

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

> p.s. wouldn't it be useful to give cp an option to copy attributes
> but not data, i.e. instead of the touch and chmod in the example above,
> one could do: cp --attributes-only --preserve=all "$file" "$tf"
> or alternatively give a --preserve=all option to `touch`?

I like the idea of adding an option to cp.
It already knows how to preserve XATTR and SELinux context, and more.
I found myself doing something similar to the above,
but also had to use

    chcon --reference=...

Then we can keep touch relatively simple.

Sami, thanks for contributing!
BTW, if you'd like to continue, please look at the guidelines in
  http://git.sv.gnu.org/cgit/coreutils.git/plain/HACKING
In particular, see the section on copyright assignment.