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_reut...@web.de>
To: r-help@r-project.org
Subject: [R] Bug in list.files(full.names=T)
Message-ID:
<caawr5bony3dizfw9hrrua1dvoxyfcwst7tw5fnqfuhboiml...@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.dun...@gmail.com>
To: Mario Reutter <mario_reut...@web.de>, r-help@r-project.org
Subject: Re: [R] Bug in list.files(full.names=T)
Message-ID: <67096ee7-054d-0e89-cc44-6ca702307...@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 <maech...@stat.math.ethz.ch>
To: Mario Reutter <mario_reut...@web.de>
Cc: <r-help@r-project.org>
Subject: Re: [R] Bug in list.files(full.names=T)
Message-ID: <25024.17119.584361.442...@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
______________________________________________
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.
