[Top][All Lists]

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

Re: [PATCH] in place option for unexpand

From: Jim Meyering
Subject: Re: [PATCH] in place option for unexpand
Date: Sun, 22 Mar 2009 08:22:27 +0100

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
In particular, see the section on copyright assignment.

reply via email to

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