From cstrato at aon.at  Tue Mar 27 21:05:09 2007
From: cstrato at aon.at (cstrato)
Date: Tue, 27 Mar 2007 21:05:09 +0200
Subject: [Rd] Limitation of dirname() and basename()
In-Reply-To: <971536df0703271157m30f48281of787093a8a4d5c4a@mail.gmail.com>
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>
	<971536df0703271157m30f48281of787093a8a4d5c4a@mail.gmail.com>
Message-ID: <46096AE5.1010606@aon.at>

Gabor Grothendieck wrote:
> 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/")
>
>
Thank you, I like your first suggestion very much, it is very elegant.
(dirname2() is also a possibility but not so elegant.)
Best regards
Christian



[Rd] Limitation of dirname() and basename()
cstrato