[R] Bug in list.files(full.names=T)

[Jorgen Harmse]

There is a possibly related problem in file.path. As Murdoch says, it's ugly even if the OS accepts it, and I don't see that the base version is any better than paste(sep=fsep, ...). Pasting the result into emacs wouldn't work. I wrote my own version to remove trailing fsep from all but the last argument.

> base::file.path('foo/','bar')
[1] "foo//bar"
> file.path('foo/','bar')
[1] "foo/bar"

Incidentally, I don't like T & F for Booleans (or t for transpose) in production code. Single letters are too useful for local variables, so I would say TRUE, FALSE, & base::t.

Jorgen Harmse.



    Message: 1
    Date: Sat, 18 Dec 2021 15:55:37 +0100
    From: Mario Reutter <mario_reutter using web.de>
    To: r-help using r-project.org
    Subject: [R] Bug in list.files(full.names=T)
    Message-ID:
    	<CAAWr5boNy3Dizfw9HrruA1dvoXyFcwsT7Tw5fnqfUhBOimLKog using mail.gmail.com>
    Content-Type: text/plain; charset="utf-8"

    Dear everybody,

    I'm a researcher in the field of psychology and a passionate R user. After
    having updated to the newest version, I experienced a problem with
    list.files() if the parameter full.names is set to TRUE.
    A path separator "/" is now always appended to path in the output even if
    path %>% endsWith("/"). This breaks backwards compatibility in case path
    ends with a path separator. The problem occurred somewhere between R
    version 3.6.1 (2019-07-05) and 4.1.2 (2021-11-01).

    Example:
    >> list.files("C:/Data/", full.names=T)
    C:/Data//file.csv

    Expected behavior:
    Either a path separator should never be appended in accordance with
    the documentation: "full.names
    a logical value. If TRUE, the directory path is prepended to the file names
    to give a relative file path."
    Or it could only be appended if path doesn't already end with a path
    separator.

    My question would now be if this warrants a bug report? And if you agree,
    could someone issue the report since I'm not a member on Bugzilla?

    Thank you and best regards,
    Mario Reutter

    	[[alternative HTML version deleted]]




    ------------------------------

    

    Message: 3
    Date: Sun, 19 Dec 2021 07:24:06 -0500
    From: Duncan Murdoch <murdoch.duncan using gmail.com>
    To: Mario Reutter <mario_reutter using web.de>, r-help using r-project.org
    Subject: Re: [R] Bug in list.files(full.names=T)
    Message-ID: <67096ee7-054d-0e89-cc44-6ca702307196 using gmail.com>
    Content-Type: text/plain; charset="utf-8"; Format="flowed"

    I don't know the answer to your question, but I see the same behaviour 
    on MacOS, e.g. list.files("./") includes ".//R" in the results on my 
    system.  Both "./R" and ".//R" are legal ways to express that path on 
    MacOS, so it's not a serious bug, but it does look ugly.

    Duncan Murdoch

...


    ------------------------------

    Message: 10
    Date: Mon, 20 Dec 2021 09:46:23 +0100
    From: Martin Maechler <maechler using stat.math.ethz.ch>
    To: Mario Reutter <mario_reutter using web.de>
    Cc: <r-help using r-project.org>
    Subject: Re: [R] Bug in list.files(full.names=T)
    Message-ID: <25024.17119.584361.442267 using stat.math.ethz.ch>
    Content-Type: text/plain; charset="us-ascii"

...

    This expected behavior has never been documented AFAIK.
    I tried R 3.6.1 on Linux  and it already behaved like that:  If
    you append a path separator  it is kept in addition to the new
    one even though it's not needed:

    > list.files("/tmp", "^[abc]", full.names = TRUE)
    [1] "/tmp/check_proc__localuser"

    > list.files("/tmp/", "^[abc]", full.names = TRUE)
    [1] "/tmp//check_proc__localuser"

    Why would one ever *add* a final unneeded path separator, unless
    one wanted it?

    Note that the default is  ".",  not "./"  ..

    I think the change you see made R-for-Windows compatible
    to the rest of the univeRse where list.files() aka dir() always
    behaved like this.

    I agree that ideally this would have been mentioned in some of
    the NEWS; maybe it *is* mentioned in the rw-faw (R for Windows
    FAQ) or other R for Windows news.. ?


        > My question would now be if this warrants a bug report?

    I don't think so.
    As I'm saying above, I think this has rather been a bug fix,
    making R more universal / less platform-dependent.

    Last but not least: You'd ideally update more than every 2.5 years...

    Best,
    Martin Maechler