Re^4: file::move and networks

Un*x does not do that, you need 'mv -f file1 file2' to force the mv on existing file.

Strange. I guess things have changed since Re^3: A DWIM too far?. Like maybe they inverted to the default behaviour? {Thor] must be real disappointed.

Play with rename a little on your system, because I doubt that that Perl has changed it's defaults to match. It certainly hasn't on my platform, despite that it had safe semantics from the get go.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Comment on Re^4: file::move and networks

Replies are listed 'Best First'.
Re^5: file::move and networks by sgt (Deacon) on Jul 16, 2007 at 11:56 UTC
I must have read your post too quickly (sorry) and with a Unx bias I guess. What I meant is the following. rename(2)* semantics on Unx 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 Unx 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. Unx rename semantics is not enough in practice and usually you want something closer to the Unx 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...	[reply]

Replies are listed 'Best First'.

Re^5: file::move and networks
by sgt (Deacon) on Jul 16, 2007 at 11:56 UTC

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.

[reply]