Re: Why --backup-and-modify-in-place in perltidy config? - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Why --backup-and-modify-in-place in perltidy config?
Date
Msg-id 20160823002031.GF13292@momjian.us
Whole thread Raw
In response to Re: Why --backup-and-modify-in-place in perltidy config?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, Aug 15, 2016 at 10:19:12AM -0400, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
> > On 08/14/2016 04:38 PM, Tom Lane wrote:
> >> I did a trial run following the current pgindent README procedure, and
> >> noticed that the perltidy step left me with a pile of '.bak' files
> >> littering the entire tree.  This seems like a pretty bad idea because
> >> a naive "git add ." would have committed them.  It's evidently because
> >> src/tools/pgindent/perltidyrc includes --backup-and-modify-in-place.
> 
> BTW, after experimenting with this, I did not find any way to get perltidy
> to overwrite the original files without making a backup file.

Yep, that's why --backup-and-modify-in-place had to be used.  I have a
local script to remove file with specified extentions, but didn't
document that cleanup step.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+                     Ancient Roman grave inscription +



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Server crash due to SIGBUS(Bus Error) when trying to access the memory created using dsm_create().
Next
From: Craig Ringer
Date:
Subject: Re: PATCH: Batch/pipelining support for libpq