Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: v3.1.4 Files/mv bug
- X-seq: zsh-workers 4431
- From: Phil Pennock <phil@xxxxxxxxxxxxxxxxxxxxx>
- To: zefram@xxxxxxxxx (Zefram)
- Subject: Re: v3.1.4 Files/mv bug
- Date: Wed, 14 Oct 1998 18:38:23 +0100 (BST)
- Cc: zsh-workers@xxxxxxxxxxxxxxx
- In-reply-to: <199810140948.KAA20183@xxxxxxxxxxxxxxxxx> from Zefram at "Oct 14, 98 10:48:00 am"
Typing away merrily, Zefram produced the immortal words:
> This is a deliberate feature. The logic is that you can't actually move
> files across devices, and the purpose of mv is to move files, so mv can't
> move files across devices. The historical versions that do a copy and
> remove are actually providing behaviour radically different from what
> mv is intended for. If you want a copy and remove, rather than a move,
> you can use cp and rm yourself.
So, just how POSIX-compliant is zsh aiming to be? What does POSIX
actually require, anyway?
I can see that the extra logic in a shell is not as ... pleasant ... as
just a couple of system calls. But, either the shell could do it
correctly or if the link(2) fails with EXDEV then automatically use the
one in the PATH. This is a nice compromise, IMNSHO, since it allows
efficiency in many cases whilst still providing 'expected' (if not
actually required?) behaviour.
Alternatively, since they're both GPL'ed, just rip the code from the
FSF's GNU shell-utils or wherever mv(1) normally lives ...
Surely mv is /intended/ to be used as history mandates. Hey, otherwise,
why not redefine O_RDONLY & O_WRONLY to be toggle-bits with
O_RDWR=(O_RDONLY|_WRONLY) on a new POSIX system. It's correct. Just
brain-dead and stupid. Similarly for fudging mv.
Perplexed (and opinionated),
--
--> Phil Pennock ; GAT d- s+:+ a22 C++(++++) UL++++/I+++/S+++/H+ P++@ L+++
E-@ W(+) N>++ o !K w--- O>+ M V !PS PE Y+ PGP+ t-- 5++ X+ R !tv b++>+++ DI+ D+
G+ e+ h* !r y?
Messages sorted by:
Reverse Date,
Date,
Thread,
Author