Hi Ralf,
On 2008-08-07 15:41:55 +0200, Ralf Wildenhues wrote:
> * Vincent Lefevre wrote on Thu, Aug 07, 2008 at 03:16:29PM CEST:
> > This is not really a bug, but this makes the code quite strange and
> > probably not very maintainable. /usr/bin/autom4te contains:
> >
> > foreach my $file (map { $_ . $req->id } ($tcache, $ocache))
> > {
> > use File::Copy;
> > move ("${file}t", "$file")
> > or fatal "cannot rename ${file}t as $file: $!";
> > }
> >
> > The "use File::Copy;" should be at the beginning of the script
> > because it is global[*]
>
> Is this just a code cleanliness issue?
Yes.
> AIUI then 'use File::Copy;' at the beginning of the script does the
> same thing as the use here.
Yes.
> So IMVHO it is very maintenance-friendly to put the statements
> together with the code that needs it as that facilitates
> copy-and-pasting the code around, for example.
Well, the problem is that other parts of the script can still use it,
and it makes difficult to see where problem comes from. The following
would be cleaner and completely local (so, no risks of side effects):
require File::Copy;
File::Copy::move (...
> Of course, if that 'use' were not idempotent, or if the module were
> used all over the map in the file, then it would make more sense to
> put it at the beginning.
>
> > (and is also there for the second "move" in the script).
>
> Where would that be?
Line 591 in Debian's /usr/bin/autom4te.
if ($atomic_replace && !rename("$output.tmp", "$output")) {
move ("${output}.tmp", "$output")
or fatal "cannot rename ${output}.tmp as $output: $!";
}
I spent some time before finding what was defining this "move"...
BTW, I did this while debugging
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=494112
As a workaround of this bug, you should flush the file before calling
"move" (or even close it if it is no longer needed).
--
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
