Re: pg_ctl strangeness under msys

Magnus Hagander wrote:

>>I have seen some strange things using pg_ctl under MSys:
>>
>>. "pg_ctl status" from the command line logs to the event log.
>>Apparently it thinks it's not on a tty. Works fine from
>>Windows cmd prompt.
>>. this hangs: perl -e '@foo=`pg_ctl -w start`;'
>> but this doesn't: perl -e 'system("pg_ctl -w start");'
>>
>>Finding the problem with the last one has cost me hours in
>>trying to get the buildfarm to run.
>>
>>Anyone have ideas about ways to fix? Or do we just note it
>>and live with it?
>>
>>
>
>As I'm sure you are already aware we've had a lot of problems with the
>msys console. Buffernig and others. I think we at some point decided to
>say that minor issues on the win32 consoles isn't really something we're
>concerned about, people will run things from the cmd console in 99.9% of
>all cases.
>
>Not sure how to fix it. The eventlog checking code uses isatty() IIRC,
>and that one is clearly returning the wrong thing on msys. Not sure how
>to code around that.
>
>

The only way I can think of is an explicit flag that says "tell me on
the console". Probably not worth worrying about - just a fact to keep in
mind in case other people get confused as I did.

>As for the perl command, what perl is this? ActiveState or MingW? Do you
>get the same problem if you run it in the cmd.exe environment, or only
>in the msys console?
>
>
>

It's the perl from the MSys DTK.

This all came about from trying to get my buildfarm script (written in
perl) running on Windows. I have to use the MSys DTK perl for that
because it is the only one that understands MSys virtual paths - tried
ASPerl and Cygwin perl and it blew up both times. Complicating the
situation is the fact that the DTK perl apparently isn't selfhosted, so
installing needed CPAN modules on it is next to impossible. This means
that I'm actually going to have to use 2 different perl's for the
Windows buildfarm (!) - the DTK version for the build portions and one
of the others (I am testing using ASPerl) for the web transaction part
(which used LWP, MIME:Base64 and DIgest::SHA1). Add to that the fact
that the DTK perl doesn't even have Storable.pm and you will see how
ugly it gets. But it's still worth doing. :-) I haven't even looked yet
at adding in the extras (like SSL, plpython, pltcl, plperl).

Bottom line: these are problems that annoyed and frustrated me, but
won't affect ordinary users.

cheers

andrew