Re: Is this a bug in pg_current_logfile() on Windows?

Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> writes:
> On 7/9/20 10:44 AM, Tom Lane wrote:
>> Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> writes:
>>> On 7/8/20 10:40 PM, Tom Lane wrote:
>>>> The most likely theory about that, I think, is that IPC::Run::run already
>>>> translated any \r\n occurrences in the psql command's output to plain \n.

>> It's not hard to believe that the latter two are using a different libc
>> implementation, but how would that affect the behavior of the TAP
>> infrastructure? Are they also using different Perls? (By hypothesis,
>> the pg_current_logfile bug exists across all Windows builds, so we have
>> to explain why the TAP tests only reveal it on some of these animals.)

> But the perls they are using are indeed different - msys animals have to
> use msys' perl for TAP tests because native perl doesn't understand msys
> file paths. Conversely, MSVC animals must use native perl (AS or
> Strawberry) to run TAP tests. So jacana and fairywren, the two msys
> animals, are doing what you expect5ed and drongo and bowerbird, the two
> MSVC animals, are not.

Ah-hah. So this leads to the conclusion that in native perl, IPC::Run
is doing \r\n conversion for us while in msys perl it is not.

Therefore, we either should figure out how to get msys perl to do
that conversion (and remove it from our code altogether), or make the
conversions conditional on "is it msys perl?". I am not quite sure
if the existing tests "if $Config{osname} eq 'msys'" are a legitimate
implementation of that condition or not --- it seems like nominally
they are checking the OS not the Perl, but maybe it's close enough.

regards, tom lane