zsh-workers
 help / color / mirror / code / Atom feed
From: Phil Pennock <phil@athenaeum.demon.co.uk>
To: zefram@tao.co.uk (Zefram)
Cc: zsh-workers@math.gatech.edu
Subject: Re: v3.1.4 Files/mv bug
Date: Wed, 14 Oct 1998 18:38:23 +0100 (BST)	[thread overview]
Message-ID: <199810141738.SAA02973@athenaeum.demon.co.uk> (raw)
In-Reply-To: <199810140948.KAA20183@diamond.tao.co.uk> 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?


  parent reply	other threads:[~1998-10-14 17:38 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-10-13 23:04 Phil Pennock
1998-10-14  9:48 ` Zefram
1998-10-14 14:46   ` PATCH: v3.1.4 Files/mv bug is a feature Bart Schaefer
1998-10-14 15:07   ` v3.1.4 Files/mv bug Dan Nelson
1998-10-14 17:38   ` Phil Pennock [this message]
1998-10-14 17:46     ` Zefram
1998-10-14 18:05       ` Phil Pennock
1998-10-14 18:41       ` Bart Schaefer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=199810141738.SAA02973@athenaeum.demon.co.uk \
    --to=phil@athenaeum.demon.co.uk \
    --cc=zefram@tao.co.uk \
    --cc=zsh-workers@math.gatech.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).