[...]
Harry wrote:
>> require File::Temp;
>> use File::Temp ();
Dermot queried:
> Does this refer to the standard module or something else. If you are
> (and I hope you are) using the standard File::Temp module then
> substitute this:
>
>> require File::Temp;
>> use File::Temp ();
Dermot continued:
> for this:
>
> use File::Temp qw/ tempfile/;
Jim G also noted:
>> require File::Temp;
>> use File::Temp ();
> You only need one of the two preceding lines. The 'use File::Temp()'
> would normally be preferred.
>
Harry replies:
First off, thanks to you both for the detailed responses. Very
helpful when a respondor has read and considered the subject post,
then took time to respond with detailed answers.
What happened there was the result of my own confusion with the
perldoc pages on File::Temp
It isn't really clear what they are suggesting here:
(From perldoc File::Temp.. when the notes about OOp usage start)
[...]
Object interface:
require File::Temp;
use File::Temp ();
[...]
I even remember thinking, when I looked it up with perldoc, that I
might be getting it wrong. But the errors didn't sound particularly
derived from those lines.
Thanks for clearing that up. I still mostly just see red when the OOP
stuff is shown, I've had my hands full learning the old way..
[...]
>> use File::Copy;
Dermot commented:
> It might be best to put this at the top of your script with all the
> other loadable modules your using.
Harry asks:
Do you think it would make a difference in how the script behaves? Or
do you mean for the sake of general tidiness and clarity?
(wrapped for mail --ed HP)
>> print "Copying $BashHistory to
>> ".$BashHistory."-". PaddedDateStr()."\n"; copy( $BashHistory,
>> $BashHistory . "-" . PaddedDateStr() ) or die "Copy
>> failed: $!";
Dermot suggests
> To help narrow down the problem, I would change the above to
>
> my $newname = $BashHistory . "-" . PaddedDateStr();
> if (-e $BashHistory) {
> copy($BashHistory, $newname) or die "Can't copy $BashHistory ->
> $newname: $!\n";
> }
> else {
> print "Can't find $BashHistory\n";
> }
Harry responds:
Ahh yes, I hadn't even considered that ~/.bash_history might be
absent. But now you mention it, I recall more than one occasion when
mine was absent for some reason... I don't recall the reason now but
it was evidence of some deeper problem as I recall.
Dermot continued:
> The error is being reported by File::Copy::copy, so it would be useful
> to know that your passing to it as well as ensuring that the file
> exists prior to asking for the file to be copied.
>
> I suspect there is some un-foreseen interaction between File::Temp and
> File::Copy. I wonder what version of perl you are using.
Harry writes:
Jim also suggested that might be the case.
> Hopefully this might provide some clues to what there error stem from.
Thanks for the input.. I'm thinking of following Jim Gs' reasoning and
just ditch both of the modules. Since there is not a pressing need for
a random temp file.. And the copy operation is such a light usagee.
Maybe just do both manually.
> At 2:11 AM -0500 10/18/09, Harry Putnam wrote:
>>I'm not sure what these errors are telling me.
Jim Gibson <jimsgib...@gmail.com> writes:
> I have not used File::Temp nor File::Copy very much. However, I think
> you are not using File::Temp in its intended way, according to the
> documentation. What version of File::Temp are you using? I have
> version 2.11 on my system under Perl 5.10.
Ok, you both asked about version information:
About the version of perl: I'm using version 5.8.8
About the version of File::Temp: Its probably something obvious but
I'm not sure how to tell the version of File::Temp.
Scanning the *.pm file: /usr/lib/perl5/5.8.8/File/Temp.pm (using vim)
I followed the hits on the search string /[Vv]ersion but none of them
appeared to be about the version of File::Temp
On a whim I tried `perl /usr/lib/perl5/5.8.8/File/Temp.pm --version'
but that just gave me the prompt back.
Harry's error output:
>>./uniqbh.pl
>> Copying ./bash_history to ./bash_history-101809_020827
>> Unlinking ./bash_history
>> Copying /tmp/lPlN3goGnI.tmp ./bash_history
>> Operation "eq": no method found,
>> left argument in overloaded package File::Temp,
>> right argument has no overloaded magic at
>> /usr/lib/perl5/5.8.8/File/Copy.pm line 76, <BASH_HISTORY> line 18151.
>
Jim suggests some analysis:
> Look at line 76 in the file /usr/lib/perl5/5.8.8/File/Copy.pm. If it
> is in routine copy or _eq, then it is either 1) trying to figure out
> if you have passed it a file handle or a file name, or 2) trying to
> figure out if you are trying to copy a file onto itself. In either
> case, it is getting confused by the arguments to the copy routine that
> you have provided.
>
That sounds likely
[...]
>From Harrys' comments in the script:
>># [HP 101709_220324 Unlink is set to 1 by default .. that
>># means it will be unlinked when the object goes out of scope
>># so setting it to 0 means I have to delete (unlink) it manually
>>my $tmpfile = new File::Temp( UNLINK => 0, SUFFIX => '.tmp' );
Jim analyzes further:
> The File::Temp::new method returns an object which can be treated as a
> file name or as an open file handle. The new method opens the file, so
> the following open statement is unnecessary. You should use $tmpfile
> as a file handle. However, File::Copy may be confused by passing it a
> File::Temp object instead of a normal file handle.
Harry responds:
Yes, I see your reasoning.. and it is sounding more likely.
>>open(TMPFILE,">$tmpfile") or die "Can't open $tmpfile: $!";
>>
Jim suggests a possible solution:
> I would re-think your program design and avoid using both File::Temp
> and File::Copy. I probably wouldn't use either. If you already know
> the name of the file you want to create, then just create it with an
> open.
Harry tries a weak defense for using File::Temp:
Somewhere I got the notion that when you need a tmp file.. the best
way was to use File::Temp. But you are right, there really is no
pressing need for randomness..back to KISS.
In fact I should probably open the same file name with `>' every time
the script runs and not even have to worry about unlinking. Just
leave it alone and overwrite it on each run.
Jim comments further:
> Instead of opening your bash history file twice, open it once,
> read the file to get the number of lines, then rewind the file with
> the seek() method.
Harry writes:
Good point, but is it really any better? I got the routine for
counting lines from an old post of Chas Owens here. As I recall, he
argued at that time that it was simpler and maybe even faster to just
simulate the unix command `wc -l' in the way you see in the script.
I don't recall the full context though so it may have been quite
different that what I'm doing.
In terms of KISS.. it might be more KISS like to do it the way I did.
Do you think using seek would be more efficient or faster? Or maybe
just more logical?
Jim continues:
> . . . . . . . . Then, read the lines from the input history file,
> ignore redundant lines except for the last twelve, and write the lines
> to the new file. No modules required, and no file copying either.
Harry responds:
I like the sound of that.. KISS right down the line.
Jim continues:
> Since bash history files are [ NOT (--ed added by HP) ] that big,
> you could also read the file into an array, get the number of
> elements in the array, and write out the array accordingly.
Harry responds:
Another idea I also considered. My bash_history is near 18,000 lines
but I'm increasing it to 36,000 limit.
I'm not sharp enough to know what kind of numbers begin to make an
array, not such a good idea. Maybe you know or have a rough idea
about that?
The script runs on a fairly powerful machines, Intel P4s with 3.2 Ghz
and 3GB ram and an Athlon64 +3400 with 2.2 Ghz and 3GB ram.
Some what dated now but still quite a lot of power.
I think I'll rewrite the script now and see if can get a clean run.
Thanks.
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
