I am glad to hear that there seems to be some commitment for improvement,
although I must admit, that I did not realize that both functions do not
check
if a name is a directory or a filename, even though the definition in "The
Open Group Base Specifications" says:
dirname - return the directory portion of a pathname
basename - return non-directory portion of a pathname
Using basename() and dirname() I tried to define functions, which show
what I wanted to do:
file.name <- function(fullname, name.exists=T) {
isdir <- file.info(fullname)[,"isdir"]
if (is.na(isdir)) return(ifelse (name.exists, NA, basename(fullname)))
ifelse (isdir, "", basename(fullname))
}
file.dir <-function(fullname, name.exists=T) {
isdir <- file.info(fullname)[,"isdir"]
if (is.na(isdir)) return(ifelse (name.exists, NA,
file.dir(dirname(fullname))))
path.expand(ifelse (isdir, fullname, dirname(fullname)))
}
Here are some examples:
> file.name("/net/home/stratowa/Diverses/tmp.txt")
[1] "tmp.txt"
> file.name("/net/home/stratowa/Diverses/")
[1] ""
> file.name("/net/home/stratowa/Diverses")
[1] ""
> file.dir("/net/home/stratowa/Diverses/tmp.txt")
[1] "/net/home/stratowa/Diverses"
> file.dir("/net/home/stratowa/Diverses/")
[1] "/net/home/stratowa/Diverses/"
> file.dir("/net/home/stratowa/Diverses")
[1] "/net/home/stratowa/Diverses"
To get the filename part for a novel filename, I can set "name.exists=F".
I think, that it would be really helpful, if R could add these (or similar)
functions to the base package, but this is my personal opinion.
Best regards
Christian
Simon Urbanek wrote:
>
> On Mar 27, 2007, at 5:42 PM, Herve Pages wrote:
>
>> Simon Urbanek wrote:
>>> Your proposed behavior is inconsistent, anyway. The purpose of
>>> dirname is to return parent directory of the entity represented by
>>> the pathname.
>>
>> Mmmm, I don't think this is true:
>>
>>> dirname("aaa/..")
>> [1] "aaa"
>>
>> "aaa" is not the parent directory of "aaa/.."
>>
>> Same here:
>>
>>> dirname("/usr/./.")
>> [1] "/usr/."
>>
>
> Yes, the problem is that most dirname implementations don't
> canonicalize the path - they are working on the string representation
> and don't use the underlying FS. I wasn't saying that dirname is
> perfect, in fact I refrained from commenting on this earlier exactly
> because of the behavior you describe, but the decision to remove
> trailing slashes was a deliberate as can be seen from the specs.
> Semantically correct behavior (taking the definition of the dirname
> function literally) would be dirname "/usr/." = "/", basename "/usr/."
> = "usr". However, I suspect that not many people would expect this ;).
> As was proposed earlier, one could think of "true" dirname" or perhaps
> better "parentdir" function, although admittedly I don't see an issue
> here ...
>
> Cheers,
> Simon
>
>
>
>>
>>> "/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.
>>
>> Note that Python's designers were not afraid to emancipate from Unix for
>> this particular case:
>>
>>>>> import os.path
>>>>> os.path.dirname("aaa/..")
>> 'aaa'
>>>>> os.path.dirname("aaa/../")
>> 'aaa/..'
>>
>>
>> Also note that, if the goal was to mimic Unix behaviour, then why not
>> fully go for it, even for edge-cases:
>>
>> R
>> ----
>>> dirname("/")
>> [1] "/"
>>> basename("/")
>> [1] ""
>>
>> Unix
>> ----
>> [EMAIL PROTECTED]:~> dirname "/"
>> /
>> [EMAIL PROTECTED]:~> basename "/"
>> /
>>
>> Just my 2 cents...
>>
>> Cheers,
>> H.
>>
>>
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
