{"thread":{"id":"14840","subject":"[PATCH] git-cvsimport.perl: Print \"UNKNOWN LINE...\" on stderr, not stdout.","startedAt":"2008-08-05T14:54:42Z","lastAt":"2008-08-05T15:44:03Z","messageCount":4,"participants":["Jim Meyering","Jeff King"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"86274","messageId":"87zlnro6kt.fsf@rho.meyering.net","threadId":"14840","inReplyTo":null,"subject":"[PATCH] git-cvsimport.perl: Print \"UNKNOWN LINE...\" on stderr, not stdout.","fromName":"Jim Meyering","fromEmail":"jim@meyering.net","sentAt":"2008-08-05T14:54:42Z","receivedAt":"2008-08-05T14:54:42Z","isPatch":true,"sender":{"key":"jim@meyering.net","avatar":"https://avatars.githubusercontent.com/u/710630?v=4"},"body":"\nSigned-off-by: Jim Meyering <meyering@redhat.com>\n---\nI'm used to filtering git-cvsimport's noisy stderr, but this\ndiagnostic appears on stdout.  Looks like an oversight.\nNow that I'm using cvsps-2.2b1, I see tons of these.\n\n git-cvsimport.perl |    2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ndiff --git a/git-cvsimport.perl b/git-cvsimport.perl\nindex e2664ef..e439202 100755\n--- a/git-cvsimport.perl\n+++ b/git-cvsimport.perl\n@@ -952,7 +952,7 @@ while (<CVS>) {\n \t} elsif (/^-+$/) { # end of unknown-line processing\n \t\t$state = 1;\n \t} elsif ($state != 11) { # ignore stuff when skipping\n-\t\tprint \"* UNKNOWN LINE * $_\\n\";\n+\t\tprint STDERR \"* UNKNOWN LINE * $_\\n\";\n \t}\n }\n commit() if $branch and $state != 11;\n--\n1.6.0.rc1.36.g5ff70\n"},{"id":"86275","messageId":"20080805152836.GB21901@sigill.intra.peff.net","threadId":"14840","inReplyTo":"87zlnro6kt.fsf@rho.meyering.net","subject":"Re: [PATCH] git-cvsimport.perl: Print \"UNKNOWN LINE...\" on stderr, not stdout.","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-08-05T15:28:36Z","receivedAt":"2008-08-05T15:28:36Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Aug 05, 2008 at 04:54:42PM +0200, Jim Meyering wrote:\n\n> I'm used to filtering git-cvsimport's noisy stderr, but this\n> diagnostic appears on stdout.  Looks like an oversight.\n> Now that I'm using cvsps-2.2b1, I see tons of these.\n\nThere are a ton of things that go to stdout:\n\n  $ perl -ne '/print (\\S+)/ && print \"$1\\n\" git-cvsimport.perl |\n    grep '^#' | wc -l\n  18\n\nthough many are only activated via \"-v\". Maybe it is worth putting all\nof them to stderr? I really don't see why cvsimport should ever produce\nany output on stdout.\n\n-Peff\n"},{"id":"86276","messageId":"20080805153558.GA22111@sigill.intra.peff.net","threadId":"14840","inReplyTo":"20080805152836.GB21901@sigill.intra.peff.net","subject":"Re: [PATCH] git-cvsimport.perl: Print \"UNKNOWN LINE...\" on stderr, not stdout.","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-08-05T15:35:59Z","receivedAt":"2008-08-05T15:35:59Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Aug 05, 2008 at 11:28:36AM -0400, Jeff King wrote:\n\n>   $ perl -ne '/print (\\S+)/ && print \"$1\\n\" git-cvsimport.perl |\n>     grep '^#' | wc -l\n\nUrgh, somehow I managed to get a typo into my cut and paste. It should be\n\n  grep '^\"'\n\n(i.e., we are getting rid of \"print STDERR\" and \"print $fh\"; this is\nadmittedly not very robust, but I just wanted an approximation of how\nmany there were).\n\n-Peff\n"},{"id":"86277","messageId":"87tzdzo4ak.fsf@rho.meyering.net","threadId":"14840","inReplyTo":"20080805152836.GB21901@sigill.intra.peff.net","subject":"Re: [PATCH] git-cvsimport.perl: Print \"UNKNOWN LINE...\" on stderr, not stdout.","fromName":"Jim Meyering","fromEmail":"jim@meyering.net","sentAt":"2008-08-05T15:44:03Z","receivedAt":"2008-08-05T15:44:03Z","isPatch":true,"sender":{"key":"jim@meyering.net","avatar":"https://avatars.githubusercontent.com/u/710630?v=4"},"body":"Jeff King <peff@peff.net> wrote:\n> On Tue, Aug 05, 2008 at 04:54:42PM +0200, Jim Meyering wrote:\n>\n>> I'm used to filtering git-cvsimport's noisy stderr, but this\n>> diagnostic appears on stdout.  Looks like an oversight.\n>> Now that I'm using cvsps-2.2b1, I see tons of these.\n>\n> There are a ton of things that go to stdout:\n>\n>   $ perl -ne '/print (\\S+)/ && print \"$1\\n\" git-cvsimport.perl |\n>     grep '^#' | wc -l\n>   18\n>\n> though many are only activated via \"-v\". Maybe it is worth putting all\n> of them to stderr? I really don't see why cvsimport should ever produce\n> any output on stdout.\n\nA quick scan (post-patch)\n\n    $ grep 'print ' git-cvsimport.perl|grep -vE 'STDERR|opt_v'\n    print $f \"$_=$conv_author_name{$_} <$conv_author_email{$_}>\\n\";\n    print $fh $line;\n    print $fh $buf;\n    print $cvspsfh $_;\n    print $fh\n    print \"SKIPPING $fn v $rev\\n\";\n\nsuggests that if you don't count the \"SKIPPING...\" diagnostic you'd get\nfor each \"-S REGEXP\"-skipped name, the \"UNKNOWN LINE\" diagnostic is the\nonly one that goes to stdout but that is not protected by an $opt_v guard.\n"}]}