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

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

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.

> 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Anastasia Lubennikova 2016-08-15 14:45:58 Re: WIP: Covering + unique indexes.
Previous Message Andrew Dunstan 2016-08-15 14:12:32 Re: Why --backup-and-modify-in-place in perltidy config?