Idiom for shelling out to $EDITOR/$PAGER?

Cameron Simpson cs at zip.com.au
Fri Dec 23 01:32:16 EST 2011


On 23Dec2011 17:12, Ben Finney <ben+python at benfinney.id.au> wrote:
| Cameron Simpson <cs at zip.com.au> writes:
| > On 22Dec2011 22:16, Tim Chase <python.list at tim.thechases.com> wrote:
| > | -proper & efficient detection of file-change, to know whether the
| > | user actually did anything
| >
| > Wait for the editor to exit?
| > In that scenario I go for:
| >   - wait for edit to exit
| >   - if exit status 0 and file non-empty, trust it
| >     (subject to parse issues afterwards of course)
| 
| That doesn't address the concern Tim raised: did the user actually do
| anything, did the file change?

I'm not sure it matters. It's _quicker_ to do nothing if the file is
unchanged, but is it bad to act on it anyway?

| The exit status of text editors are not bound to distinguish “buffer was
| modified”, and certainly don't do so in any standard way.

Indeed not; my 0 above is just "did you user exit the editor or did it
crash"?

| My advice:
| * Compute a before-edit hash of the text (MD5 or SHA-1 would be fine).
| * Invoke the editor on that text.
| * Wait for (or detect) the exit of the editor process.
| * Compute an after-edit hash of the text resulting from the editor.
| * Compare the hashes to see whether the text changed.

Sure. But still, if you're able to act on a changed file, why not also
act on an unchanged file? The user asked to change things; take what you
got back and proceed!

And personally, as a user, I've often rewritten an unchanged file to
force a recompute of something.

Cheers,
-- 
Cameron Simpson <cs at zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/

"Don't you know the speed limit is 55 miles per hour???"
"Yeah, but I wasn't going to be out that long."
        - Steven Wright



More information about the Python-list mailing list