Re: A DWIM too far?

Replies are listed 'Best First'.
Re^2: A DWIM too far? by adrianh (Chancellor) on Jun 17, 2004 at 12:59 UTC
Some people may find "reasonable behavior" and "what Unix does" not entirely synonymous in all situations ;-)	[reply]
Re^3: A DWIM too far? by tbone1 (Monsignor) on Jun 17, 2004 at 14:29 UTC
BLASPHEMER! Ladies, get your beard and rocks, it's time for a stoning! </OB_Python> -- tbone1, YAPS (Yet Another Perl Schlub) And remember, if he succeeds, so what. - Chick McGee	[reply]
Re^3: A DWIM too far? by thor (Priest) on Jun 17, 2004 at 18:33 UTC
I know that your tongue was in your cheek, but I don't need to take off my shoes to know that Unix has been around for longer than Windows has with fewer changes to basic things such as this. While this is a poor measure of correctness, I think it says something. But, as with all things Unix, if you want the hand holding, you can have it. Change 'mv' to 'mv -i' in my example and it won't clobber the file without asking first. Windows and the like assume that you're stupid and that they know better. I don't like that one bit. thor	[reply]
Re^4: A DWIM too far? by adrianh (Chancellor) on Jun 17, 2004 at 23:39 UTC
Unix has been around for longer than Windows has with fewer changes to basic things such as this. While this is a poor measure of correctness, I think it says something. It says something. Quite what it says is open to question. Of course the behaviour makes sense to Unix heads familiar with how the C rename() operates. Which is a plus. Less to learn. Apart from this, and being simple to implement, is it a good decision? demerphq says that it's "much more common to want to rename things and overwrite what was there before". This is reasonable, but (after a quick grep of the Perl I have laying around) it doesn't match my experience. The current behaviour certainly makes coding some operations harder. If `rename` failed if the new filename existed we could do: `rename( $old, $new ) \|\| die $!;` [download] and be certain that $new won't be damaged if it already exists. However, with the current behaviour we either have to abandon `rename` completely and spend a lot of time and effort doing sneaky stuff, or do something like : `! -e $new && rename( $old, $new) \|\| die $!` [download] which is both longer to type, and has a race condition (`$new` could be created between the `die` and the `rename`). Personally I would prefer `rename` to fail by default with an option to overwrite. It would make my code more robust.	[reply] [d/l] [select]
Re^5: A DWIM too far? by mpeppler (Vicar) on Jun 18, 2004 at 14:07 UTC
Re^6: A DWIM too far? by adrianh (Chancellor) on Jun 18, 2004 at 14:14 UTC
A reply falls below the community's threshold of quality. You may see it by logging in.
Re^2: A DWIM too far? by tachyon (Chancellor) on Jun 18, 2004 at 00:05 UTC
"touch temp1 temp2; mv temp2 temp1"? You'll be left with only temp1. No doubt that is true on your system but on RedHat flavour Linux you will get a prompt before the overwrite: [root@devel3 root]# touch temp1 temp2; mv temp2 temp1 mv: overwrite `temp1'? n [download] cheers tachyon	[reply] [d/l]
Re^3: A DWIM too far? by hv (Prior) on Jun 18, 2004 at 00:53 UTC
I think you'll find that this happens only because RedHat sets up by default an alias (for root only) that rewrites 'mv' to 'mv -i'. Hugo	[reply]
Re^4: A DWIM too far? by tachyon (Chancellor) on Jun 18, 2004 at 01:04 UTC
It is as you say. `[root@devel3 root]# cat .bashrc [snip] # User specific aliases and functions alias mv='mv -i'` [download] cheers tachyon	[reply] [d/l]


more useful options
	PerlMonks