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

From Tom Lane
Subject Re: Why --backup-and-modify-in-place in perltidy config?
Date
Msg-id 6816.1471270752@sss.pgh.pa.us
Whole thread Raw
In response to Re: Why --backup-and-modify-in-place in perltidy config?  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: Why --backup-and-modify-in-place in perltidy config?  (Andrew Dunstan <andrew@dunslane.net>)
Re: Why --backup-and-modify-in-place in perltidy config?  (Michael Paquier <michael.paquier@gmail.com>)
Re: Why --backup-and-modify-in-place in perltidy config?  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
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.

> We should probably specify -bext='/', which would cause the backup files 
> to be deleted unless an error occurred.

Really?  That seems a bit magic, and it's certainly undocumented.

> Alternatively, we could just remove the in-place parameter and write a 
> command that moved the new .tdy files over the original when perltidy 
> was finished.

I was thinking about just removing all the .bak files afterwards, ie
automating the existing manual process.  As long as we're making an
invocation script anyway, that's easy.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Why --backup-and-modify-in-place in perltidy config?
Next
From: Anastasia Lubennikova
Date:
Subject: Re: WIP: Covering + unique indexes.