[bug] commands output inconsistence

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alexander Belchenko wrote:
> Matthieu Moy пишет:
>> Alexander Belchenko <bialix at ukr.net> writes:
>>> So, what the answer on my question: is the output of some commands (such
>>> a 'commit') that print their output to stderr should be readable by user
>>> or not?
>>
>> Of course it should be readable.
>>
>> Your bug is that you have unreadable output. Yes, that's a bug. But
>> what you propose (write to stdout instead of stderr) is a workaround,
>> not a solution. It should obviously be used only if there is no
>> solution.
> 
> Probably my english skill is too bad or I simply too dumby to understand
> why different command should emit their information output to different
> streams.

In general, there is the concept of 'things you want to capture'. For
something like 'bzr diff' you want to capture the actual diff contents.

So in general, stuff that is actual data goes to stdout, and stuff that
is just informative messages to the user goes to stderr.

'bzr commit' is only user informative stuff.

You *can* capture both with:

bzr commit -m 'foo' >foo 2>&1

That says 'redirect stdout to a file, and redirect stderr to the same
place'.

Or you can keep them separate with:

bzr commit -m "foo" 2>err 1>out

> 
> I try to talk not about workarounds. I try to talk about consistency.
> Consistency of output of different bzr commands.
> 
> If I understand correctly there is several types of bzr output:
> 
> - errors and warnings messages
> - progress bar (each command could potentially has progress bar)
> - informational output
> 
> If I understand correctly errors, warnings, progress bar printed to
> stderr, and all informational output printed to stdout.

Not really. It depends on the command.

> 
> Per example, bzr log for remote location:
> it prints progress bar to stderr when it download info from remote
> location, but then prints actual log to stdout.
> 
> All the time I was think that all informational output is printed to
> stdout. But today I see: I was wrong. But I don't understand why. May be
> someone could explain this. Explanation from Eric seems not user
> friendly for me. It's a machine friendly. But I repeat this again:
> probably I too dumb or too windows user.

Well, stdout is meant for machine friendly. The specific bug we have is
that we aren't treating stderr as encoded, and we should.

> 
> So, if all developers think that usual output of commit command is not
> informational and should not be emited to informational channel -- I'll
> give up.
> 

The output of commit is arguable in either direction. But we need to fix
writing to stderr in general. And I believe if we fix writing to stderr,
then things should work properly for you.

> I simply wanted to have ability easy redirect output of commands to
> file. It could be useful for creating examples for documentation or for
> preparing bug reports.
> 
> -- 
> Alexander

Just redirect both stderr and stdout, and you should be fine.

Please file a bug on failing to write in proper encoding when writing to
stderr. You can file a bug about 'commit should write to stdout', so we
don't forget to bring that up later. Since 'commit' has no real output,
it might be okay for it to write the added files to stdout.
Also, be aware that there is a commit --verbose, which prints out other
information as well, and we need to determine what should go where.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEx287JdeBCYSNAAMRAplKAJ9wp74cEDZw1mCQJP0wJMDfqosurACgvwFt
M8806zpWYyAqEBIQasScV3o=
=5dAN
-----END PGP SIGNATURE-----