I must have read your post too quickly (sorry) and with a Un*x bias I guess. What I meant is the following.
rename(2) semantics on Un*x is pretty consistent these days given by the "single Unix spec". One could argue ad infinitum if a good choice of semantics was made: rename just clobbers destination if it exists. IMHO this is a decent choice consistent with the positive bias Un*x calls have had from the start, which was permit as much as possible as fast as possible, OK when you look at the whole library construction from a legolike perspective.
I just tested rename with perl5.8.3 on HP-UX 11.0, and perl5.8.7 cygwin-1.5.24-2, and perl just follows the underlying lib. semantics as perldoc says. Sadly this means that the direct use of rename is likely to be non-portable, but is usually the case when you have a direct interface to system calls.
Un*x rename semantics is not enough in practice and usually you want something closer to the Un*x mv(1) semantics also defined by "the single unix spec". Especially mv does a copy/delete action when src and dest are on different filesystems. Giving us a portable useful interface should be the purpose of File::Copy:move and friends.
I remember some heated discussion on p5p (around 5.8.0 I guess) about having select with character semantics, and the motivation for some was essentially that windows does it. IMHO the whole thing was madness and a bad application of the "DWIM principle". I guess that perl, due to its Un*x heritage has given us incondicional access to low level libs, the "makes hard things possible" principle, but "DWIM" should apply to clean, powerful, platform-ind and useful abstractions.
cheers --stephan p.s the version of the "Single Unix Spec" used is v.2, pretty old...In reply to Re^5: file::move and networks
by sgt
in thread file::move and networks
by philc
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |