R devel - Sep 2009 - basename returns "." not in filename (PR#13958)

Full_Name: Jens Oehlschl?gel
Version: 2.9.2
OS: Win32
Submission from: (NULL) (85.181.152.156)


# Obviously an empty basename is allowed (if the filepath is a pure
path)
> basename("/")
[1] ""

# but here we get the dot from the path
> basename("./")
[1] "."
> version
               _                           
platform       i386-pc-mingw32             
arch           i386                        
os             mingw32                     
system         i386, mingw32               
status                                     
major          2                           
minor          9.2                         
year           2009                        
month          08                          
day            24                          
svn rev        49384                       
language       R                           
version.string R version 2.9.2 (2009-08-24)

joehl at web.de wrote:
> Full_Name: Jens Oehlschl?gel
> Version: 2.9.2
> OS: Win32
> Submission from: (NULL) (85.181.152.156)
> 
> 
> # Obviously an empty basename is allowed (if the filepath is a pure path)
>> basename("/")
> [1] ""
> 
> # but here we get the dot from the path
>> basename("./")
> [1] "."
Command line utility does likewise:

viggo:~/>basename ./
.

Point is, I gather, that trailing slashes are removed, e.g.,

viggo:~/>basename foo/
foo

So, not a bug.

-- 
   O__  ---- Peter Dalgaard             ?ster Farimagsgade 5, Entr.B
  c/ /'_ --- Dept. of Biostatistics     PO Box 2099, 1014 Cph. K
 (*) \(*) -- University of Copenhagen   Denmark      Ph:  (+45) 35327918
~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk)              FAX: (+45) 35327907

On Sep 18, 2009, at 12:11 , Peter Dalgaard wrote:
> joehl at web.de wrote:
>> Full_Name: Jens Oehlschl?gel
>> Version: 2.9.2
>> OS: Win32
>> Submission from: (NULL) (85.181.152.156)
>>
>>
>> # Obviously an empty basename is allowed (if the filepath is a pure  
>> path)
>>> basename("/")
>> [1] ""
>>
>> # but here we get the dot from the path
>>> basename("./")
>> [1] "."
>
> Command line utility does likewise:
>
> viggo:~/>basename ./
> .
>
> Point is, I gather, that trailing slashes are removed, e.g.,
>
> viggo:~/>basename foo/
> foo
>
> So, not a bug.
>
Indeed. The rationale is that foo/bar/ specifies a directory "bar" at
the path "/foo", hence the name is "bar" ("" would
make no sense of
course).

Cheers,
Simon

Mmh,
> > Point is, I gather, that trailing slashes are removed, e.g.,
> >
> > viggo:~/>basename foo/
> > foo
> >
> > So, not a bug.
This unfortunately means that we cannot distinguish between 
1) a path with a filename
2) a path without a filename

For example in the next version of the ff-package we allow a user to specify a
'pattern' for all files of a ff dataframe which is path together with a
fileprefix, the above means we cannot specify an empty prefix "" for
the current working directory, because
> dirname("./.")
[1] "."
> basename("./.")
[1] "."
> dirname("./")
[1] "."
> basename("./")
[1] "."

Jens Oehlschl?gel

Jens,

On Sep 18, 2009, at 15:08 , Jens Oehlschl=E4gel wrote:
> Mmh,
>
>>> Point is, I gather, that trailing slashes are removed, e.g.,
>>>
>>> viggo:~/>basename foo/
>>> foo
>>>
>>> So, not a bug.
>
> This unfortunately means that we cannot distinguish between
> 1) a path with a filename
> 2) a path without a filename
>
Of course you can - but that's unrelated to the bug report.

> For example in the next version of the ff-package we allow a user to =20
> specify a 'pattern' for all files of a ff dataframe which is path
=20
> together with a fileprefix, the above means we cannot specify an =20
> empty prefix "" for the current working directory, because
>
>> dirname("./.")
> [1] "."
>> basename("./.")
> [1] "."
>> dirname("./")
> [1] "."
>> basename("./")
> [1] "."
>
I don't see the connection - I would suggest you read the IEEE Std =20
1003.1-2001 which defines the behavior of basename (and the R =20
documentation for basename clearly states the behavior as well).  The =20
fact that you are trying to use the wrong tool for your purpose =20
doesn't mean that the tool is broken. I would advise you to ask on R-=20
help how to implement your pattern specification (just FWIW it's non-=20
standard and requirement of trailing slashes does lead to very nasty =20
problems for the user).

Cheers,
Simon