"John W. Krahn" <jwkr...@shaw.ca> writes: > Harry Putnam wrote: >> I'm not sure what these errors are telling me. >> >> The script is supposed to remove dups from .bash_history > > Wouldn't it be simpler to set HISTCONTROL to ignoredups: > > export HISTCONTROL=ignoredups > > Or: > > export HISTCONTROL=ignoreboth
Yes of course.. I know and use HISTCONTROL like your second example. This script was a way to keep up and expand somewhat, my tiny perl skills. But also there have been occasions when I wanted to know how many times I'd ran a command. It can come up when coding and testing as you go. I just guessed at leaving 12.. it may need more like 20-26. [...] >> require File::Temp; >> use File::Temp (); > > Those two lines both do the same thing. Pick *one*. Thanks... So I've heard else where in this thread. It doesn't take much to confuse me.. and the way the documentation of File::Temp was written it appeared (to me)to be saying to use both. [...] >> my $tmpfile = new File::Temp( UNLINK => 0, SUFFIX => '.tmp' ); > > Usually written as: > > my $tmpfile = File::Temp->new( UNLINK => 0, SUFFIX => '.tmp' ); Oh.. thanks.. I just took the example from perldoc near verbatim. >> open(TMPFILE,">$tmpfile") or die "Can't open $tmpfile: $!"; > > Why are you opening the file again? You already have a writable > filehandle in $tmpfile. I didn't quite get that the file was opened in that first operation. >> ## Keep this many lines from being processed, but do include them >> ## in the final file. >> my $KeepLines = 12; >> my $ProcessLines = (count_lines($BashHistory) - $KeepLines); >> >> ##### BEGIN Body ##### ##### ##### >> open(BASH_HISTORY,"<$BashHistory")or die "Can't open $BashHistory: >> $!"; >> while (<BASH_HISTORY>) { >> chomp; >> ## Process all but $KeepLines >> if($. <= $ProcessLines){ >> ## finds unique input lines and prints them to a separate file >> if ($data{$_}++ == 0) { >> print TMPFILE $_ . "\n"; > > Why chomp the newlines off and then just add them back on again? I learned to be leery of including newlines and just automatically chomp them. I've had problems arise and had trouble tracking them down, finally to find, it was induced by the presence of a new line. I don't often know what all my `while' loop is going to do until I start writing it. I often find that what I wanted to do, changes as I go. So for me, chomping right off the reel, means I always know how to treat the print action. Maybe when I'm more confident of my perl skills I will know in advance when chomping will be an unneeded extra move. >> } >> }elsif($. > $ProcessLines){ >> print TMPFILE $_ . "\n"; } >> } > > open my $BASH_HISTORY, '<', $BashHistory or die "Can't open > $BashHistory: $!"; > while ( <$BASH_HISTORY> ) { > ## Process all but $KeepLines > if ( $. <= $ProcessLines ) { > ## finds unique input lines and prints them to a separate file > next if $data{ $_ }++; > } > print $tmpfile $_; > } Haa, you turned it around, shortening it too... very nice. >> close(TMPFILE); >> >> use File::Copy; >> >> print "Copying $BashHistory to >> ".$BashHistory."-". PaddedDateStr()."\n"; copy( $BashHistory, >> $BashHistory . "-" . PaddedDateStr() ) >> or die "Copy failed: $!"; >> >> print "Unlinking $BashHistory\n"; >> unlink $BashHistory; > > unlink $BashHistory or die "unlink failed: $!"; Whoops, I should have caught that one... thanks. [...] > perldoc -q "How do I count the number of lines in a file?" Thanks for including the search sting too. I `borrowed' that snip of code in my script from an old post by Chas Owens here, but why is the way described in perldoc ( $lines = 0; open(FILE, $filename) or die "Can't open `$filename': $!"; while (sysread FILE, $buffer, 4096) { $lines += ($buffer =~ tr/\n//); } close FILE; ) better? >> sub PaddedDateStr { >> my ($mon,$mday,$year,$hour,$min,$sec,$wday) = >> (localtime(time))[4,3,5,2,1,0,6]; >> # $year += 1900; ## prints 2005 $year -= 100; ## prints 05 >> (with %02d) > > If you were writing this ten years ago you would now have a negative > number in $year. If this is still in use one hundred years from now > you will now have a three digit number in $year. Use modulus instead. Yup, I see that now.. >> $mon += 1; >> my $PaddedDateStr = sprintf "%02d%02d%02d%s%02d%02d%02d", >> $mon,$mday,$year,"_",$hour,$min,$sec; >> return $PaddedDateStr; >> } > > Or just: > > sub PaddedDateStr { > my ( $sec, $min, $hour, $mday, $year ) = localtime; > return sprintf '%02d%02d%02d_%02d%02d%02d', $mon + 1, $mday, $year > % 100, $hour, $min, $sec; > } > > But why are you using Month-Day-Year order? Your file names would > sort better in Year-Month-Day order. I never gave a moments thought to sorting. Its just that I'm so used to looking at strings like 101209_132140 and knowing at a quick glance what the date is . I may have to get used to year first, because that sorting thing could be of some consequence when you've written a whole herd of them. > Or use the POSIX::strftime function: > > use POSIX 'strftime'; > sub PaddedDateStr { > return strftime '%m%d%y_%H%M%S', localtime; > } Now that is a big help... I've fumbled around with localtime array quite a bit a few times. Finally writing that sub routine a yr or so ago, and keeping it in a personal library to just read into a new script when ever I needed a zero padded date string. That POSIX module looks like just the ticket. > This may work better for you: > #!/usr/bin/perl [...] Oh, nice... many thanks for such a professional looking script. The truth is though I will need to study on this a while to get familiar with what is going on there...And look up and study some of the (unfamiliar to me) items introduced. I envy your ability to just whip out stuff like this... thanks for taking time to do it. A nice piece of homework you've given me. Part of my reason for even writing this script was to keep whatever little skills I've finally acquired and maybe learn a bit too. Working my way through your script will be good jump on that aspect. One thing here, I'm considering completely ditching both File::Temp and File::Copy Can you tell me if there are good reasons to stick with File::Temp in this situation? When I thought about it a bit after being prompted by Jim G in this thread. I realized I didn't have a good reason to be concerned about randomness or clobbering etc, with my new working file. I'm on a single user machine at home. I'm thinking I could just write to /tmp/BashHistoryDeDup.tmp with the `>' flag, overwriting on each run and forget unlinking Again thanks for the nice piece to study on. -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/