Re: Why --backup-and-modify-in-place in perltidy config?

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Why --backup-and-modify-in-place in perltidy config?
Date: 2016-08-15 18:19:22
Message-ID: 57B207AA.3000608@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 08/15/2016 10:19 AM, Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)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.

We must be using different versions.

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

WFM.

cheers

andrew

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Shay Rojansky 2016-08-15 18:23:03 Re: Slowness of extended protocol
Previous Message Dave Cramer 2016-08-15 18:19:05 Re: Slowness of extended protocol