[plugin] binary sys.stdout/err on win32

[Alexander Belchenko]

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)

I don't want to dispute this moment but I think that older version of
Mac OS (where \r was used as line-endings of text files) also has
concept of 'text mode'. I always think about 'text mode' as about flag
that specify mode when file is opened (in C language).

>>>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.

Well, if I have files with \r\n line-endings then my diff will contain
line-endings like \r\r\n that clearly distinct from plain \r\n. And
patch utility that runs in --binary mode does right thing with both file
types. And win32-port of patch does not like diffs with \n-only
line-endings. That's why I prefer have behaviour compatible with
'patch'. And no one has problem with my patches when I send diffs to
this mailing list (at least no one complains ;-).

> 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.

Not for all. Only for python sources because this project should be
Linux-compatible. On pure C-project that I develop and compile on win32
and for win32-only I don't control line-endings.

> 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.

'diff --strict' is good. I like it.

>>>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.

Right, but by default (by double-clicking file in Explorer) notepad is
launched.

>>>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 think if we can forcing to switch it on/off for test suite we don't
lose anything in selftest.

>>>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?
> 
> 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').

Shelf plugin use msvcrt.getch() function for reading only one char at
time. Reading password actualy does through special function that also
rely on msvcrt -- probably there is no problems but I suggest to test it
first.

--
Alexander