Print progress message to stderr, not stdout
PATCH 1/1 Print progress message to stderr, not stdout
Printing progress messages to stdout causes them to get mixed up with the actual output of the program. Using stderr is much better, since the user can then redirect the two components separately.
---
I noticed this when creating a patch with "stg export -s" for the import regression test.
stgit/git.py | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-)
stgit/git.py +3 -3
@@ -186,8 +186,8 @@ def __tree_status(files = None, tree_id """Returns a list of pairs - [status, filename] """ if verbose: - print 'Checking for changes in the working directory...', - sys.stdout.flush() + sys.stderr.write('Checking for changes in the working directory...') + sys.stderr.flush() refresh_index()
@@ -226,7 +226,7 @@ def __tree_status(files = None, tree_id cache_files.append(fs) if verbose: - print 'done' + print >> sys.stderr, 'done' return cache_files
Quoted 4 lines · Karl Hasselström
Printing progress messages to stdout causes them to get mixed up with the actual output of the program. Using stderr is much better, since the user can then redirect the two components separately.
This patch breaks qgit.
GUI interface to stgit pop and push commands is broken because a command that prints to stderr is considered a failing one by qgit.
I would kindly ask you to:
1 - Revert the patch. That would be the best. You can use a prefix to printed message instead, see git pull, something like 'stg: bla bla bla' . In any case, IMHO, using stderr for normal activity logging does not sound like a great idea in general.
2 - At least add a '-v' '--verbose' option that defaults to quiet so to not break back compatibility.
Thanks
Marco
P.S: I cannot change the stderr == 'something has gone wrong' behaviour because the interface to git commands works with this, and, BTW, _all_ the git commands respect the behaviour stderr == empty ->
Quoted 12 lines · Marco Costalba
Quoted 3 lines · Karl Hasselström
Printing progress messages to stdout causes them to get mixed up with the actual output of the program. Using stderr is much better, since the user can then redirect the two components separately.
This patch breaks qgit.
GUI interface to stgit pop and push commands is broken because a command that prints to stderr is considered a failing one by qgit.
I would kindly ask you to:
Quoted 7 lines
1 - Revert the patch. That would be the best. You can use a prefix to printed message instead, see git pull, something like 'stg: bla bla bla' . In any case, IMHO, using stderr for normal activity logging does not sound like a great idea in general.
2 - At least add a '-v' '--verbose' option that defaults to quiet so to not break back compatibility.
Since there are other tools relying on a clean stderr, I think I would revert it and add a verbose flag and/or config option. Karl, any thoughts on this (since you sent the patch)?
Quoted 9 lines · Catalin Marinas
Quoted 7 lines · Marco Costalba
Quoted 4 lines · Karl Hasselström
Printing progress messages to stdout causes them to get mixed up with the actual output of the program. Using stderr is much better, since the user can then redirect the two components separately.
Quoted 5 lines
Quoted 1 line
This patch breaks qgit.
Since there are other tools relying on a clean stderr, I think I would revert it and add a verbose flag and/or config option. Karl, any thoughts on this (since you sent the patch)?
I introduced this since I wanted to divert the output to a file, and the progress message had no business being written to that file. But a command line option to suppress progress messages would work just as well if that's what git does.
Signature · 1 line
Karl Hasselström, [email protected]
Quoted 13 lines · Karl Hasselström
Quoted 11 lines · Catalin Marinas
Quoted 8 lines · Marco Costalba
Quoted 4 lines · Karl Hasselström
Printing progress messages to stdout causes them to get mixed up with the actual output of the program. Using stderr is much better, since the user can then redirect the two components separately.
This patch breaks qgit.
Quoted 9 lines
Quoted 3 lines
Since there are other tools relying on a clean stderr, I think I would revert it and add a verbose flag and/or config option. Karl, any thoughts on this (since you sent the patch)?
I introduced this since I wanted to divert the output to a file, and the progress message had no business being written to that file. But a command line option to suppress progress messages would work just as well if that's what git does.
If you don't mind I would prefer a command line option to _enable_ progress messages, something like -v or --verbose so to keep back compatibility with current versions of tools that do not expect stderr messages.
Thanks
Quoted 10 lines · Marco Costalba
Quoted 4 lines · Karl Hasselström
I introduced this since I wanted to divert the output to a file, and the progress message had no business being written to that file. But a command line option to suppress progress messages would work just as well if that's what git does.
If you don't mind I would prefer a command line option to _enable_ progress messages, something like -v or --verbose so to keep back compatibility with current versions of tools that do not expect stderr messages.
I'll first move the message back to stdout. Does qgit rely on the StGIT output to have a certain format/information? Does the progress message affect it in any way?
I consider many of the other messages to be progress messages (like "pushing... done") and I haven't differentiated between them until Karl's patch. For commands like diff or status, you expect the command to check the working copy anyway and it doesn't output this specific message.
The best would probably be to add a "verbose" config option to enable this message (and maybe a command line option later but this means modifying all the commands to accept this option). I'll try to push this change tomorrow (together with moving from stgitrc to gitconfig).
Hi,
Quoted 1 line · Catalin Marinas
I'll first move the message back to stdout.
In other parts of git, the progress message is only printed if output goes to a tty. Why not do the same?
Ciao,
Dscho
Quoted 5 lines · Johannes Schindelin
Quoted 1 line · Catalin Marinas
I'll first move the message back to stdout.
In other parts of git, the progress message is only printed if output goes to a tty. Why not do the same?
Thanks for the hint. This seems to me like the easiest solution.
Quoted 6 lines · Johannes Schindelin
Quoted 1 line · Catalin Marinas
I'll first move the message back to stdout.
In other parts of git, the progress message is only printed if output goes to a tty. Why not do the same?
That sounds like a good idea for two reasons:
1. It will address all concerns raised in this thread (I think).
2. It will remove an unnecessary difference between git and stgit.
Signature · 1 line
Karl Hasselström, [email protected]
Quoted 7 lines · Catalin Marinas
Quoted 6 lines · Marco Costalba
Quoted 4 lines · Karl Hasselström
I introduced this since I wanted to divert the output to a file, and the progress message had no business being written to that file. But a command line option to suppress progress messages would work just as well if that's what git does.
Quoted 9 lines
Quoted 4 lines
If you don't mind I would prefer a command line option to _enable_ progress messages, something like -v or --verbose so to keep back compatibility with current versions of tools that do not expect stderr messages.
I'll first move the message back to stdout. Does qgit rely on the StGIT output to have a certain format/information? Does the progress message affect it in any way?
No. It just checks stderr for empty.
The only commands whose output is used by qgit are stg series/applied/u