From owner-cvs-bin  Sat Oct  7 11:19:54 1995
Return-Path: owner-cvs-bin
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id LAA12879
          for cvs-bin-outgoing; Sat, 7 Oct 1995 11:19:54 -0700
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA12869
          ; Sat, 7 Oct 1995 11:19:46 -0700
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id EAA32435; Sun, 8 Oct 1995 04:18:24 +1000
Date: Sun, 8 Oct 1995 04:18:24 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199510071818.EAA32435@godzilla.zeta.org.au>
To: CVS-commiters@freefall.freebsd.org, bde@freefall.freebsd.org,
        cvs-bin@freefall.freebsd.org
Subject: Re: cvs commit: src/bin/mv mv.c
Sender: owner-cvs-bin@FreeBSD.org
Precedence: bulk

>  Modified:    bin/mv    mv.c
>  Log:
>  Handle trailing slashes in source filenames correctly.  E.g., rewrite
>  `mv foo/ ../..' to `mv foo/ ../../foo/', not to `mv foo/ ../../'.  The
>  latter caused a panic.  Before the trailing slash changes in the kernel,
>  the trailing slashes caused the rename() for this mv to fail earlier, so
>  there was no panic in 2.0.
>  
>  Fixes part of PR 760.

This change should (:-) be in 2.1.

It's interesting that the usual method for finding the basename (see
more/ commands.c for a topical example of the usual method) doesn't
actually work.  cp(1) does similar things to mv(1) and gets the basename
right by stripping trailing slashes.  Stripping trailing slashes isn't
quite right for the spacial path "//" but there is no problem with this
in cp or mv since a source path of "//" or "/" is invalid for other
reasons.  basename(1) already handles trailing slashes correctly except
it strips them all.  basename.c has many comments that seem to be direct
quotes from POSIX.2 to help it DTRT.  basename.1 seems to be out of sync
with the sources and is confusing.

Bruce