moving a file in a filesystem-independent way?
fperez528 at yahoo.com
Fri Jan 31 21:18:05 CET 2003
Geoff Gerrietts wrote:
> Quoting Fernando Perez (fperez528 at yahoo.com):
>> This problem is nasty because the structure of unix filesystems is
>> such that things can change drastically from one machine to
>> anonther. It's the first time that I find python being 'dumber'
>> than the plain shell commands.
>> But I'm sure it's me being dumb, not python :) So I'd appreciate any
>> enlightenment on why things are this way, or how I should go about
>> the problem.
> As recently as 8 years ago, mv was that dumb, too. On some Unix
> systems, it still is.
Ah. I've only been usling linux for just about 8-9 years, so I never
> The issue of transparency stands behind your problem. The functions in
> os.posix (and consequently available in os) are very close to the
> functions provided by the standard C library on your Linux system. The
> standard library's rename() function (man 2 rename) returns an error
> in the event that the source and destination are not on the same
> The convenience function you propose makes sense, but I'm not sure if
> replacing rename() is the right solution -- a new method called move
> might be preferable, to avoid confusion.
I totally agree that rename should reflect the underlying posix behavior
faithfully. But as others have pointed, this seems a reasonable enough
request that shutils just grew a move() for python 2.3. I'm just a bit
surprised to read that it didn't exist before, I can hardly imagine being
the first to complain about this one.
At any rate, thanks a lot to all who replied (Francois, Inyeol, Geoff,...).
Informative and quick, as is the norm in c.l.py. I'll work manually around
the issue until I can safely assume that 2.3 is on all my machines (not for
More information about the Python-list