in reply to extract useful infos from cvs diff output

#!/usr/bin/perl -w use strict; use Text::Tabs; # core module die "Usage: real_diff.pl file.txt [file2.txt ..]\n" unless @ARGV; my $prev_line; my $file; while(<>) { $file = $1 if /^RCS file: (.*?),/; if(/^.{62}[<>\|]/) { if(not $prev_line or $prev_line < $. - 1) { print "=" x 70, "\n"; print "Line number in $ARGV.txt: $.\n"; print "Source file name: $file\n\n"; } print expand($_); $prev_line = $.; } }

Makeshifts last the longest.

Replies are listed 'Best First'.
Re: Re: extract useful infos from cvs diff output
by pg (Canon) on Jan 31, 2003 at 06:46 UTC
    Text::Tabs does tab replacing, but that module uses a global variable $tabstop (which is a style I really hate, to me, any package shows this kind of style will not be considered)

    It might be too much to expect it to be OO, but at least $tabstop should be a parameter to expand, instead of being a global.

    The other thing is that you obviously chopped too much useful stuffs away:
    1. Exception handling has to be there. I don't expect my program to show any compilation warnings/errors or run time warnings/errors. That's simply not my style.

      If there is an exception, my code should catch it and handle it, not Perl.

    2. File handling. Result would be stored in file regardless. I do not expect anyone to pipe them from command line. Those outputs might be stored as document.

      "...but that module uses a global variable $tabstop (which is a style I really hate, to me, any package shows this kind of style will not be considered)"

      Oh please! I suppose this means that you will stop using just about every CPAN module then, since most of them use the global variable $VERSION? If it gets the job done, is stable, is robust, then i won't knock it just because the author might have 'skimmed' a little and used a global or two. Sometimes, once in a blue moon, using globals provides a more elegant solution.

      For example, Data::Dumper uses a global variable to set the indent level, $Indent. Sure, i would rather have a method to set that level, but i am not going to dismiss that module as worthless just because of one little wart ... <update>which Aristotle just showed me how to remove (thanks Aristotle!)</update>

      jeffa

      run this on your top level CPAN module install dir:
      perl -MFile::Find::Rule -e '@ARGV=File::Find::Rule->file("*.pm")->in(" +.");while(<>){print if /^\$VERSION/}' | wc -l
        Hmm..
        print Data::Dumper->new(\%foo)->Indent(3)->Dump;
        Nevertheless, I use the global a lot of the time.

        Makeshifts last the longest.

      I'd like to think the stuff I removed in my version added flexibility.

      The global variable in Text::Tabs irritates me too, but we're talking about a 10-liner utility script here. I don't use strictures on oneliners either, you know.

      Your "exception handling" message is misleading. If the open fails due to permission problems, your message still says the script found no file. The diamond operator will produce a good error message: detailing the operation (opening in this case), filename and reason for failure ($!). Note that it will not look like a Perl error - it doesn't contain the "at line [..]" bits.

      I don't see any exception handling on your write-open either. That's an issue I just forgo entirely by printing to STDOUT and letting the user take care of it.

      And finally, if I ever change my mind about my file naming conventions, this script will not have to be touched. To me, that's very important. I try to write my utility scripts with the Unix toolset philosophy in mind and so far, it's paid off.

      Makeshifts last the longest.