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

[Martin Maechler]

>>>>> Martin Maechler 
>>>>>     on Mon, 20 Dec 2021 09:46:23 +0100 writes:

>>>>> Mario Reutter 
>>>>>     on Sat, 18 Dec 2021 15:55:37 +0100 writes:

    >> 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.

    > 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.. ?

On the other hand, now that I tried it,
on the Windows Terminal Server 2016 I've access to,
I see what you said *was* your previous behavior, i.e.,
I see this {R code with comments for what I see} :

##
str(c0 <- list.files("C:/"))
## chr [1:23] "$Recycle.Bin" "536F22AB9746" "Boot" "bootmgr" "BOOTNxsXT" ...
str(c1 <- list.files("C:/Boot", full.names=TRUE))
str(c1s <- list.files("C:/Boot/", full.names=TRUE))# extra '/' at end
## but even here, the extra trailing '/' does *not* harm
all(c1 == c1s) ## TRUE !

The above, using ESS and plain RGui Windows *and* Rstudio;
for ESS in the following of my (dozen or so on Windows server) R versions :
R 3.6.1, 4.0.0, 4.1.1, 4.1.2

... so I remain quite a bit puzzled...

Maybe other R-on-Windows users can have a look?
Martin

    >> 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



    >> And if you agree, could someone issue the report since
    >> I'm not a member on Bugzilla?

    >> Thank you and best regards, Mario Reutter

    > ______________________________________________
    > R-help using r-project.org mailing list -- To UNSUBSCRIBE and
    > more, see https://stat.ethz.ch/mailman/listinfo/r-help
    > PLEASE do read the posting guide
    > http://www.R-project.org/posting-guide.html and provide
    > commented, minimal, self-contained, reproducible code.