Re: A DWIM too far?

Is this unprecedented for a rename command or function?

Unprecedented, no. This is the way Unix has always behaved. You have to explicitly ask it to warn you if things are about to be overwritten, via the -i command line switch. On the other hand, I know you happen to be (mainly) a Windows developer, and on that platform you can't rename an old file into an existing file.

And it does say here "Changes the name of a file; an existing file NEWNAME will be clobbered. "... but who reads the documentation?

Does anyone else think that this is a DWIM too far?

No, in that I am accustomed to the behaviour and in fact rely on it. I appreciate being able to rename a new file into the name of a production file and I don't care whether the file exists or not.

Nonetheless, you do have a point. According to the principle of Least Surprise, perl should probably honour the underlying rename behaviour of the OS. But that opens up another can of worms. I have lots of cross-platforms scripts written once, run on both Windows and Unix. What happens then? I like having the consistent behaviour on both systems.

Maybe what is needed is a flag in Config that lets one choose which action to take when the target exists.

PS: now, about those backups...

- another intruder with the mooring of the heat of the Perl

Comment on Re: A DWIM too far?

Replies are listed 'Best First'.
Re^2: A DWIM too far? by tye (Sage) on Jun 17, 2004 at 16:28 UTC
On the other hand, I know you happen to be (mainly) a Windows developer, and on that platform you can't rename an old file into an existing file. My recollection is that in the first "Windows" (aka "DOS"), you couldn't prevent ren nor copy from overwriting files (I recall being quite frustrated at not having "-i" and losing files as a result). In modern Windows (aka "Win32"), you are correct that "ren" refuses to overwrite files. However, "copy" and "move" both have the most sensible default IMO, they ask before overwriting. Though I find it a bit strange that "ren" refuses to overwrite files but "copy" and "move" can't be made to act the same. You can prevent "copy" and "move" from asking ("/y"), but if you do, they unconditionally and silently overwrite. As for programming APIs, my preference would be to allow the programmer to specify. Actually, I'd require the programmer to specify whether clobbering should done or an error should be returned. The API should allow this to be specified so that the operation can be done atomically. And I think no default behavior should be specified just to force the programmer to consciously make that decision, as there are cases where either behavior is inappropriate. - tye	[reply]

Replies are listed 'Best First'.

Re^2: A DWIM too far?
by tye (Sage) on Jun 17, 2004 at 16:28 UTC

On the other hand, I know you happen to be (mainly) a Windows developer, and on that platform you can't rename an old file into an existing file.

My recollection is that in the first "Windows" (aka "DOS"), you couldn't prevent ren nor copy from overwriting files (I recall being quite frustrated at not having "-i" and losing files as a result).

In modern Windows (aka "Win32"), you are correct that "ren" refuses to overwrite files. However, "copy" and "move" both have the most sensible default IMO, they ask before overwriting. Though I find it a bit strange that "ren" refuses to overwrite files but "copy" and "move" can't be made to act the same. You can prevent "copy" and "move" from asking ("/y"), but if you do, they unconditionally and silently overwrite.

As for programming APIs, my preference would be to allow the programmer to specify. Actually, I'd require the programmer to specify whether clobbering should done or an error should be returned. The API should allow this to be specified so that the operation can be done atomically. And I think no default behavior should be specified just to force the programmer to consciously make that decision, as there are cases where either behavior is inappropriate.

- tye

[reply]