If we are fiddling with normalizePath, having a way of not following symlinks (otheer than ~) would be useful as well.
I had to write normalizePath2 in switchr for a specific on-the-ground need to NOT go down all he way to physical paths on a remote compute system because of how IT handled implementing constant pathing on top of swapping out hardware, and I can't imagine i'm the only one who has ever faced such an issue. ~G On Tue, Apr 14, 2020 at 10:03 AM Dean Attali <daatt...@gmail.com> wrote: > This request stems off a bug report I posted > https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17757 where it was > determined the current behaviour is as expected. > > To recap: when given a real file, normalizePath() always* returns the full > absolute path. When given a non-existent file, normalizePath() returns a > full path on Windows but it returns the input on other systems*. I'd argue > that there are benefits to being able to reliably and consistently get a > full path, regardless of whether the file exists or not. In order to not > break existing behaviour, I propose adding an argument `absolute = FALSE` > that will attempt to return an absolute path when the argument is set to > TRUE. I don't have any evidence for this claim, but I believe that others > who use this function would expect, like I did, that an absolute path is > returned regardless of the file state. I understand the documentation is > correct because it warns the absolute path may not be returned, but I > believe it would be a useful feature to support. > > > * I've tested this on Win7, Win10, two versions of MacOS, ubuntu. This > behaviour may not be true in other OSes > > [[alternative HTML version deleted]] > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > [[alternative HTML version deleted]] ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
