From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter@eisentraut.org>
cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: pgindent vs. pgperltidy command-line arguments
In-reply-to: <45aacd8a-5265-d9da-8df2-b8e2c0cf6a07@eisentraut.org>
References: <45aacd8a-5265-d9da-8df2-b8e2c0cf6a07@eisentraut.org>
Comments: In-reply-to Peter Eisentraut <peter@eisentraut.org>
	message dated "Thu, 25 May 2023 11:10:48 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1471229.1685020832.1@sss.pgh.pa.us>
Date: Thu, 25 May 2023 09:20:32 -0400
Message-ID: <1471230.1685020832@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/1471230.1685020832%40sss.pgh.pa.us>
Precedence: bulk

Peter Eisentraut <peter@eisentraut.org> writes:
> Until PG15, calling pgindent without arguments would process the whole 
> tree.  Now you get
> No files to process at ./src/tools/pgindent/pgindent line 372.
> Is that intentional?

It was intentional, cf b16259b3c and the linked discussion.

> Also, pgperltidy accepts no arguments and always processes the whole 
> tree.  It would be nice if there were a way to process individual files 
> or directories, like pgindent can.

+1, although I wonder if we shouldn't follow pgindent's new lead
and require some argument(s).

> Attached is a patch for this.
> (It seems that it works ok to pass regular files (not directories) to 
> "find", but I'm not sure if it's portable.)

The POSIX spec for find(1) gives an example of applying find to
what they evidently intend to be a plain file:

	if [ -n "$(find file1 -prune -newer file2)" ]; then
	    printf %s\\n "file1 is newer than file2"
	fi

So while I don't see it written in so many words, I think you
can assume it's portable.

			regards, tom lane