>>>>> Martin Maechler <maech...@stat.math.ethz.ch>
>>>>> on Fri, 30 Nov 2012 11:47:07 +0100 writes:
>>>>> William Dunlap <wdun...@tibco.com>
>>>>> on Thu, 29 Nov 2012 02:36:54 +0000 writes:
>>> (even worse, path may contain '..' or
>>> likewise from a list.files(all.names=TRUE) call)
>> Would anyone's code break if "." and ".." were never in the output of
>> list.files() (or dir())? I find it tedious to skip them
>> whenever doing anything recursive in the file system. They are
>> not in the output of the unix find command and no one misses them
>> there.
> At first, I've tended to agree with your implicit proposal.
> I wouldn't be suprised if someone's code broke from such a
> change, but then I think "Some One" gets what (s)he deserves ...
> But I'm less sure now that I've looked into the issue in more
> details:
> If you use
> (1) list.files(*, all.files=TRUE) # sic! 'all.names' does not exist
> you implicitly say 'recursive=FALSE' , where
> (2) list.files(*, recursive=TRUE, ...)
> implicitly contains 'include.dirs=FALSE'
> on which the help page says
> include.dirs: logical. Should subdirectory names be included in
> recursive listings? (There always are in non-recursive ones).
> {with a typo s/There/They/ which I've corrected just now}
> Hence, call (2) always excludes "." and ".."
> Would you reall see the need for an option to exclude "."
> and ".." also from the non-recursive calls?
well,... and inspite of the above question,
as I know Bill Dunlap's good judgement and as it appeared to be
nicely implementable, I've still provided such an option now (R-devel only) :
------------------------------------------------------------------------
r61184 | maechler | 2012-11-30 12:47:23 +0100 (Fri, 30 Nov 2012) | 1 line
Changed paths:
M doc/NEWS.Rd
M src/library/base/R/files.R
M src/library/base/man/list.files.Rd
M src/main/names.c
M src/main/platform.c
list.files() gains a new optional argument "no.."
------------------------------------------------------------------------
One might discuss if we should change the current
back-compatible default
from 'no.. = FALSE' to 'no.. = TRUE'
and someone may want to try to do that in R-devel *and* check
all of CRAN (and Bioconductor ?) to see if some package code
breaks because of such a change...
> Martin Maechler, ETH Zurich
>> Bill Dunlap
>> Spotfire, TIBCO Software
>> wdunlap tibco.com
>>> -----Original Message-----
>>> From: r-devel-boun...@r-project.org
[mailto:r-devel-boun...@r-project.org] On Behalf
>>> Of Henrik Bengtsson
>>> Sent: Wednesday, November 28, 2012 6:25 PM
>>> To: R-devel
>>> Subject: [Rd] Non-recursive way to remove empty directory on Windows?
>>>
>>> Hi,
>>>
>>> file.remove(path) will remove an empty directory "on most Unix
>>> platforms", but not on Windows, cf. help("file.remove"). A workaround
>>> for Windows is then unlink(path, recursive=TRUE). However, unless
>>> you're really careful and make sure 'path' is not empty, you may
>>> delete more than you wish (even worse, path may contain '..' or
>>> likewise from a list.files(all.names=TRUE) call). Is there another
>>> *non-recursive* way to delete a single empty directory on Windows
>>> (without turning to system() calls)?
>>>
>>> Thanks,
>>>
>>> Henrik
> ______________________________________________
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
