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]]
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
On 18/12/2021 9:55 a.m., Mario Reutter wrote:> 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]]
>
> ______________________________________________
> R-help at 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.
>>>>> 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.. ? > 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
I've tried a bunch of different R versions, I can't seem to replicate
what
you described. Here's the code I used:
R.pattern <- paste0("^R-",
.standard_regexps()$valid_R_system_version, "$")
x <- list.files(dirname(R.home()), pattern = R.pattern, full.names = TRUE)
x <- x[file.info(x, extra_cols = FALSE)$isdir]
x <- file.path(x, "bin", "x64", "Rscript")
commands <- shQuote(x)
args <- c("--default-packages=NULL", "--vanilla",
"-e", shQuote(r"{
x <- list.files(c(
"./" ,
"C:/" ,
"C:/Windows/"
), full.names = TRUE)
x <- x[grepl("//", x, fixed = TRUE)]
if (length(x))
print(x)
}"))
for (command in commands) {
command <- paste(c(command, args), collapse = " ")
cat(command, "\n", sep = "")
system(command)
cat("\n")
}
which should (theoretically) open every version of R you have installed and
try the code you ran. When I ran it, I found no files with two slashes in a
row:
"C:/PROGRA~1/R/R-2.15.3/bin/x64/Rscript" --default-packages=NULL
--vanilla
-e "
x <- list.files(c(
\"./\" ,
\"C:/\" ,
\"C:/Windows/\"
), full.names = TRUE)
x <- x[grepl(\"//\", x, fixed = TRUE)]
if (length(x))
print(x)
"
"C:/PROGRA~1/R/R-3.5.3/bin/x64/Rscript" --default-packages=NULL
--vanilla
-e "
x <- list.files(c(
\"./\" ,
\"C:/\" ,
\"C:/Windows/\"
), full.names = TRUE)
x <- x[grepl(\"//\", x, fixed = TRUE)]
if (length(x))
print(x)
"
"C:/PROGRA~1/R/R-3.6.3/bin/x64/Rscript" --default-packages=NULL
--vanilla
-e "
x <- list.files(c(
\"./\" ,
\"C:/\" ,
\"C:/Windows/\"
), full.names = TRUE)
x <- x[grepl(\"//\", x, fixed = TRUE)]
if (length(x))
print(x)
"
"C:/PROGRA~1/R/R-4.0.2/bin/x64/Rscript" --default-packages=NULL
--vanilla
-e "
x <- list.files(c(
\"./\" ,
\"C:/\" ,
\"C:/Windows/\"
), full.names = TRUE)
x <- x[grepl(\"//\", x, fixed = TRUE)]
if (length(x))
print(x)
"
"C:/PROGRA~1/R/R-4.1.0/bin/x64/Rscript" --default-packages=NULL
--vanilla
-e "
x <- list.files(c(
\"./\" ,
\"C:/\" ,
\"C:/Windows/\"
), full.names = TRUE)
x <- x[grepl(\"//\", x, fixed = TRUE)]
if (length(x))
print(x)
"
"C:/PROGRA~1/R/R-4.1.1/bin/x64/Rscript" --default-packages=NULL
--vanilla
-e "
x <- list.files(c(
\"./\" ,
\"C:/\" ,
\"C:/Windows/\"
), full.names = TRUE)
x <- x[grepl(\"//\", x, fixed = TRUE)]
if (length(x))
print(x)
"
"C:/PROGRA~1/R/R-4.1.2/bin/x64/Rscript" --default-packages=NULL
--vanilla
-e "
x <- list.files(c(
\"./\" ,
\"C:/\" ,
\"C:/Windows/\"
), full.names = TRUE)
x <- x[grepl(\"//\", x, fixed = TRUE)]
if (length(x))
print(x)
"
I can't offer much more, sorry about that. Maybe your session information
could be helpful? utils::sessionInfo()
On Sun, Dec 19, 2021 at 6:40 AM Mario Reutter <mario_reutter at web.de>
wrote:
> 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]]
>
> ______________________________________________
> R-help at 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.
>
[[alternative HTML version deleted]]