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

Duncan Murdoch murdoch@dunc@n @end|ng |rom gm@||@com
Sun Dec 19 13:24:06 CET 2021

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

More information about the R-help mailing list