Magnus Hagander wrote:
However, the problem is that in backporting it we'd make a slight
behaviour change - the log file just gets LF instead of CRLF line
endings. I'm inclined to say that's a better result than living with the
bug, though.
Can't we add back the CRLF combo when writing
On Sun, Jul 29, 2007 at 07:43:34PM -0400, Andrew Dunstan wrote:
>
>
> Andreas Pflug wrote:
> >Andrew Dunstan wrote:
> >
> >>I have no idea why that's done - it goes back to the origins of the
> >>syslogger - probably because someone mistakenly thinks all WIndows
> >>text files have to have CRLF
On Sun, Jul 29, 2007 at 06:31:04PM -0400, Andrew Dunstan wrote:
>
>
> Andreas Pflug wrote:
> >Andrew Dunstan wrote:
> >
> >>>
> >>>
> I have no idea why that's done - it goes back to the origins of the
> syslogger - probably because someone mistakenly thinks all WIndows
> tex
Andreas Pflug wrote:
Andrew Dunstan wrote:
I have no idea why that's done - it goes back to the origins of the
syslogger - probably because someone mistakenly thinks all WIndows
text files have to have CRLF line endings.
I tried changing that to _O_BINARY, and calling _setmode on both the
I have not yet succeeded in turning this behaviour off (_setmode()
didn't seem to affect it). If we can't find a way to turn it off, the
only solution short of abandoning its use on Windows that I can think
of is to translate LF on input to something unlikely like 0x1C and
then translate it b
I have not yet succeeded in turning this behaviour off (_setmode()
didn't seem to affect it). If we can't find a way to turn it off, the
only solution short of abandoning its use on Windows that I can think
of is to translate LF on input to something unlikely like 0x1C and
then translate it b
Andreas Pflug wrote:
Andrew Dunstan wrote:
Not for Wordpad though, and it's pretty universal too. And Notepad
won't load a file of any great size anyway. Furthermore, we just can't
have this alongside the pipe chunking protocol, so I'm inclined to
blow it away altogether, unless there are
Andrew Dunstan wrote:
>
> Not for Wordpad though, and it's pretty universal too. And Notepad
> won't load a file of any great size anyway. Furthermore, we just can't
> have this alongside the pipe chunking protocol, so I'm inclined to
> blow it away altogether, unless there are pretty loud squawk
Andreas Pflug wrote:
Andrew Dunstan wrote:
I have no idea why that's done - it goes back to the origins of the
syslogger - probably because someone mistakenly thinks all WIndows
text files have to have CRLF line endings.
Yes this was intentional, notepad still doesn't lik
Andrew Dunstan wrote:
>>
>>> I have no idea why that's done - it goes back to the origins of the
>>> syslogger - probably because someone mistakenly thinks all WIndows
>>> text files have to have CRLF line endings.
Yes this was intentional, notepad still doesn't like LF line endings.
Not my prefe
Andreas Pflug wrote:
Andrew Dunstan wrote:
I have no idea why that's done - it goes back to the origins of the
syslogger - probably because someone mistakenly thinks all WIndows
text files have to have CRLF line endings.
I tried changing that to _O_BINARY, and calling _setmode on both the
Andrew Dunstan wrote:
>
> I have no idea why that's done - it goes back to the origins of the
> syslogger - probably because someone mistakenly thinks all WIndows
> text files have to have CRLF line endings.
>
> I tried changing that to _O_BINARY, and calling _setmode on both the
> pipe before it's
korry.douglas wrote:
I have not yet succeeded in turning this behaviour off (_setmode()
didn't seem to affect it). If we can't find a way to turn it off,
the only solution short of abandoning its use on Windows that I can
think of is to translate LF on input to something unlikely like 0x1C
Andrew Dunstan wrote:
>> Uh, see port.h, lines 212-224. If you're using the pipe() command to
>> create it, it's used.
>>
>
> No, it's the other way around :-) If you use pgpipe() on Unix you're
> calling pipe():
D'oh. You're right, of course. I'm obviously not in a state where I
should be rea
Magnus Hagander wrote:
Andrew Dunstan wrote:
I have just discovered that the recently implemented pipe chunking
protocol is broken on Windows. This is because the pipes are operating
in text mode and doing LF->CR-LF translation, so the number of bytes
received is not the number transmitted
Andrew Dunstan wrote:
>>> I have just discovered that the recently implemented pipe chunking
>>> protocol is broken on Windows. This is because the pipes are operating
>>> in text mode and doing LF->CR-LF translation, so the number of bytes
>>> received is not the number transmitted and set in the
Magnus Hagander wrote:
Andrew Dunstan wrote:
I have just discovered that the recently implemented pipe chunking
protocol is broken on Windows. This is because the pipes are operating
in text mode and doing LF->CR-LF translation, so the number of bytes
received is not the number transmitted
Andrew Dunstan wrote:
>
> I have just discovered that the recently implemented pipe chunking
> protocol is broken on Windows. This is because the pipes are operating
> in text mode and doing LF->CR-LF translation, so the number of bytes
> received is not the number transmitted and set in the proto
I have just discovered that the recently implemented pipe chunking
protocol is broken on Windows. This is because the pipes are operating
in text mode and doing LF->CR-LF translation, so the number of bytes
received is not the number transmitted and set in the protocol header.
I have not yet
19 matches
Mail list logo
