From ggrothendieck at gmail.com  Tue Mar 27 20:57:04 2007
From: ggrothendieck at gmail.com (Gabor Grothendieck)
Date: Tue, 27 Mar 2007 14:57:04 -0400
Subject: [Rd] Limitation of dirname() and basename()
In-Reply-To: <46096739.20006@aon.at>
References: <460807A7.5030405@aon.at>
	<Pine.LNX.4.64.0703270744580.9277@gannet.stats.ox.ac.uk>
	<46095818.9080703@aon.at> <46096180.5070907@cimr.cam.ac.uk>
	<46096739.20006@aon.at>
Message-ID: <971536df0703271157m30f48281of787093a8a4d5c4a@mail.gmail.com>

On 3/27/07, cstrato <cstrato at aon.at> wrote:
> Hin-Tak Leung wrote:
> > cstrato wrote:
> >> 1. I did read the help file.
> >> 2. I have my own workaround, using e.g.
> >> file.info("/my/path/")[,"isdir"]
> >> 3. This was a suggestion.
> >> 4. If you agree with me that "/my/path/" is a path, then both
> >>    "dirname()" and "dirname" give an incorrect answer.
> >> 5. Maybe, you can give me a logical reason (besides a
> >>    historical reason) why this should be the way it is.
> >
> > Can you just read "man 3 dirname" and "man 1 dirname" on any unix box?
> > Isn't "historical reason" - this is how dirname works for the last
> > 25(?) years, some people will be *very* upset if it behaves
> > differently now -
> > a good enough reason?
> >
> > HTL
> A 25 year old mistake is no reason for R to duplicate this mistake.
> >

It would be possible to have the way it works controlled by an argument
if backward compatibility is the issue:
e.g.

dirname("/my/path/", extended = TRUE)

or it would be possible to have a second command:

dirname2("/my/path/")



[Rd] Limitation of dirname() and basename()
Gabor Grothendieck