>>>>> 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@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. ______________________________________________ R-help@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.