[Rd] Limitation of dirname() and basename()
cstrato at aon.at
Tue Mar 27 23:47:52 CEST 2007
Simon Urbanek wrote:
> On Mar 27, 2007, at 2:49 PM, cstrato wrote:
>> Hin-Tak Leung wrote:
>>> cstrato wrote:
>>>> 1. I did read the help file.
>>>> 2. I have my own workaround, using e.g.
>>>> 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?
>> A 25 year old mistake is no reason for R to duplicate this mistake.
> Please read the corresponding docs before posting such nonsense
> (especially the Rationale section):
> Your proposed behavior is inconsistent, anyway. The purpose of dirname
> is to return parent directory of the entity represented by the
> pathname. "/my/path" and "/my/path/" are equivalent as they both
> represent the directory "path" whose parent is "/my", therefore
> returning "/my/path" in either case is inconsistent with the purpose
> of this function. As of trailing slashes (independently of dirname),
> sadly, some programs exploit the equivalence of both representations
> by encoding meta-information in the representation, but this behavior
> is quite confusing and error-prone. You're free to add such special
> cases to your application, but there is no reason to add such
> confusion to R.
Your explanation of dirname returning the "parent" directory sounds
reasonable, however, none of the documents mentions this.
Maybe, I do not understand the documents correctly, nevertheless I have
to accept this behavior.
More information about the R-devel