Re^2: file::move and networks

Replies are listed 'Best First'.
Re^3: file::move and networks by sgt (Deacon) on Jul 16, 2007 at 08:30 UTC
It's the unix move semantics, silently overwriting a protected file, that suck. Un*x does not do that, you need 'mv -f file1 file2' to force the mv on existing file...o maybe I did not get your comment. Now if a command tries to enforce or not (vi does e.g) the w bit on a file is another problem. cheers --stephan	[reply]
Re^4: file::move and networks by BrowserUk (Patriarch) on Jul 16, 2007 at 08:56 UTC
Unx 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."	[reply]
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]
Re^4: file::move and networks by ysth (Canon) on Jul 16, 2007 at 18:18 UTC
Unx does not do that, you need 'mv -f file1 file2' to force the mv on existing file.* No, you don't. `$ echo foo >foo $ echo bar >bar $ mv foo bar $ cat bar foo $ uname -a Linux raven 2.6.22-8-generic #1 SMP Thu Jul 12 15:59:45 GMT 2007 i686 +GNU/Linux $ mv --version mv (GNU coreutils) 5.97` [download] and from the info page: If a destination file exists but is normally unwritable, standard input is a terminal, and the `-f' or `--force' option is not given, `mv' prompts the user for whether to replace the file. (You might own the file, or have write permission on its directory.) If the response is not affirmative, the file is skipped.	[reply] [d/l]
Re^4: file::move and networks by Argel (Prior) on Jul 16, 2007 at 21:37 UTC
Un*x does not do that, you need 'mv -f file1 file2' to force the mv on existing file That's not true. The default behavior for cp, rm, and mv is to behave as if '-f' was specified on the command line. I think you are confused because all three of these commands are usually aliased to 'cp -i', 'rm -i', and 'mv -i' respectively. Run 'alias' to see this. The '-f' option is useful because it overrides the '-i', though you could also escape the alias ('\mv') or full path the comamnd ('/bin/mv') to achieve the same results.	[reply]
Re^5: file::move and networks by sgt (Deacon) on Jul 17, 2007 at 09:53 UTC
Quite true. Thanks to both of you. You need more trickery to achieve the other semantics. Probably not very portable and means there should be a special flag for "don't overwrite" mode. `% steph@ape2 (/home/stephan) % % ll $0 lrwxrwxrwx 1 steph Ninguno 47 Mar 5 15:07 /bin/ksh93 -> /usr/ast-ksh9 +3s/arch/cygwin.i386/bin/ksh93s.exe % steph@ape2 (/home/stephan) % % echo foo > foo; echo bar > bar; /bin/ls -l foo bar; /bin/mv 0<&- 2>& +- -i foo bar; cat -evnt bar -rw-r--r-- 1 steph Ninguno 4 Jul 17 11:36 bar -rw-r--r-- 1 steph Ninguno 4 Jul 17 11:36 foo 1 bar$` [download] Looking at version 3 of the single Unix Specification mv seems to indicate the above trick is ok from a standard perspective. cheers --stephan	[reply] [d/l]