[plugin] binary sys.stdout/err on win32

[John Arbash Meinel]

Alexander Belchenko wrote:
> John Arbash Meinel пишет:

...

>> I'm not sure if cygwin has msvcrt, or if sys.stdout is already in
>> binary, but I thought I would cover it, just in case.
> 
> Actually, cygwin does not have msvcrt (it's win32-only library).
> 
> Furthermore, on all platform sys.stdout is a file-like object opened in
> text mode. So on cygwin behaviour depends on cygwin installation,
> because during installation user select what type of line-endings he
> want to use (LF/CRLF).

Well, only Win32 has the concept of 'text mode'. (and cygwin sometimes
does as you mention)

> 
>> It isn't as difficult as I thought it would be. But now we need to
>> decide if we always want binary mode or not. I think commands like diff
>> and bundle definitely want binary mode set.
> 
> Command 'bundle' want binary mode. But I'm not sure about 'diff'.

Well, if your files end in '\n', and you do 'bzr diff' you will get a
patch that ends in '\r\n' for all of your files. Which IMO is not the
right thing to do.
On the other hand, you probably want the header lines to end with
whatever line endings the files use. Looking at your branch, you use
plain '\n' for all of your files.
Maybe this goes back to the diff --strict flag. Which creates a diff
that can be read by patch and exactly applied, rather than just creating
a simple diff for user review.

> 
>> The windows command console will do the right thing when seeing a plain
>> \r. The only thing I know of that doesn't handle it well is notepad, in
>> the case that you redirected the output to a file.
> 
> Yes, and because notepad is pre-installed defualt file editor/viewer, it
> create problems on windows.

Well, there is always 'wordpad' which gets it right. But it isn't in the
path by default.

> 
>> I would like to hear Alexander's position on this, as someone who works
>> within windows all the time. For myself, I always use Vim on all
>> platforms, and it copes without any problems.
> 
> I'm -1 on making this binary mode default. But I'm strongly positive to
> merge it into mainline and make them optionally available. Or for some
> commands (like 'bundle') or via some sort configuration. Per example, as
> options in bazaar.conf, like this:
> 
> [DEFAULT]
> binary=Yes/No
> 
> or via global bzr option '--binary'. But default behaviour should be
> native CRLF on win32.

This turns it on a little bit later than I would like, but I think it is
a reasonable compromise.
My concern is that all the developers will turn it on, but because the
default is off, we won't really be using it the way a new user would.

> 
>> I'm tempted to just put this code in bzr mainline, and just live with
>> it. I'm not sure exactly where it should go in the stack, I'm guessing
>> either in the 'bzr' front end, or in bzrlib.commands.main().
>>
>> The other possibility would be to just use the encoding_type that I've
>> already specified for other stuff. And if the encoding_type == 'exact'
>> set sys.stdout to binary mode. Otherwise if we are translating
>> filenames, it seems like we could translate line-endings at the same
>> time.
>>
>> Any thoughts?
> 
> -- 
> Alexander
> 

As far as Martin's suggestion to also do sys.stdin. I would consider it
if bzr actually ever read from stdin.
The only thing it reads right now is some password prompting or user
responses (uncommit takes a 'y/n').

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060619/ffd45f96/attachment.pgp