similar to: normalizePath

Displaying 20 results from an estimated 3000 matches similar to: "normalizePath"

2011 Apr 11
1
heatmap clustering dendrogram export
Hi, I am a beginner for R. I had use gplots to generate a heatmap as following: >heatmap.2(matrix, col=topo.colors(75), dendrogram="column", Rowv=FALSE, trace="none", key=TRUE, keysize=0.8, density.info="none", cexRow=0.2, cexCol=0.6) It work well. It generate heatmap whith rcolumn clustering dendrogram and I can export a very nice graph. But I don not know how
2019 Jan 24
1
Bug or undocumented behavior in normalizePath() with file system links on windows
Hello, I discovered a bug or undocumented behavior in normalizePath steps to reproduce: execute normalizePath on a folder link on windows. When you are on a non-english windows box, you likely have links in place for windows' default folders, e.g. "C:\Programme" linking to "C:\Program Files" on german windows boxes. Thus executing
2020 Mar 23
2
Inconsistant result for normalizePath on Windows
Hi all, I saw a quite surprising result in the devel R when using the function *normalizePath*. If the input is a path to a folder, the function returns an absolute path with/without a slash at the end depending on the existence of the folder. I know both results are valid on Windows but this behavior is different than R3.6, I do not know if the change in the devel version is made on purpose.
2014 Sep 07
2
normalizePath is sometimes very slow for nonexistent UNC paths
I'm having an issue with occasionally slow-running calls to normalizePath. If the path is a non-existent UNC path, then normalizePath sometimes takes 6 or 7 seconds to run, rather than its usual few microseconds. My big problem is that I can't reliably reproduce this across machines. The example below generates one or two slow runs out of 10000 on my Windows machine. I haven't been
2015 Mar 11
1
normalizePath output depends on existence of directory
Dear all, I'm not sure whether this is intended behaviour or a bug. The path returns from normalizePath is different when the directory doesn't exist. I have included a reproducible example. path <- tempfile() missing.dir <- normalizePath(path, winslash = "/", mustWork = FALSE) dir.create(path) existing.dir <- normalizePath(path, winslash = "/", mustWork =
2016 Nov 17
2
problem with normalizePath()
The packages "readxl" and "haven" (and possibly others) no longer access files on shared network drives. The problem appears to be in the normalizePath() function. The file can be read from a local drive or by functions that don't call normalizePath(). The error thrown is Error: path[1]="\\Hzndhhsvf2/data/OCPH/EPI/BHSDM/Group/17.xls": The system cannot find the
2020 Apr 14
4
Suggestion/opinions: add a `absolute` param to `normalizePath()` to force returning an absolute path
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
2016 Nov 30
1
problem with normalizePath()
I found this as well. At our institution, our home directories are on network shares that are mapped to local drives. The default, it appears, is to set the location for libraries (etc) to the network share name (//computer//share/director/a/b/user) rather than the local drive mapping (H:/). Given the issue with dir.create(), this means it's impossible to install packages (since it tries to
2016 Nov 18
2
problem with normalizePath()
>>>>> Evan Cortens <ecortens at mtroyal.ca> >>>>> on Thu, 17 Nov 2016 15:51:03 -0700 writes: > I wonder if this could be related to the issue that I > submitted to bugzilla about two months ago? ( > https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=17159) > That is to say, could it be that it's treating the first >
2010 Sep 09
1
Error in normalizePath(path) : with McAfee
Dear R People: I keep getting the "Error in normalizePath(path) :" while trying to obtain the necessary packages to use with the "Applied Spatial Statistics with R" book. I turned off the Firewall (from McAfee) but am still getting the same message. Does anyone have any idea on a solution please? > sessionInfo() R version 2.11.1 (2010-05-31) i386-pc-mingw32 locale: [1]
2006 Jun 12
1
normalizePath() warning
I've been getting the following warning after running 'install.packages()' recently: Warning message: insufficient OS support on this platform in: normalizePath(path) Does anyone know what this means? And does anyone know how I can get rid of the warning? I've just installed R on a fresh FC5 system so I feel I might have forgotten to install a package/library or something.
2008 Oct 23
1
normalizePath bug (PR#13199)
Full_Name: Joseph Haykov Version: 2.8.0 OS: Windows Submission from: (NULL) (216.189.177.202) normalizePath("C:\\DOCUME~1\\JOSEPH~1\\LOCALS~1\\Temp\\RtmpolZ4Vy\\file72ae2cd6.txt") returns: "\0354xl|\a&#144;\001?$v\001?y8" instead of returning: "C:\\Documents and Settings\\Joseph Haykov\\Local Settings\\Temp\\RtmpolZ4Vy\\file72ae2cd6.txt" By the way, this
2011 Aug 11
2
UNC windows path beginning with backslashes: normalizePath bug??
Hi, Back in June I posted the message below, but had no replies. I've made a little progress since then so this is to update anyone interested (!) and to ask for comments. Brief problem statement: Under Windows, some parts of R don't handle UNC paths beginning with backslashes. Specifically a) Sys.glob() fails to find some files breaking (e.g.) Rcmdr plugins
2010 Feb 18
0
install.packages, normalizePath, file permissions
Dear developers, I have a small but more or less well defined inquiry. Another, more general one for which I was not able to find information is towards the end of this messages. The question seems to be too technical for R-help, that is why I post it here. When installing packages (Windows XP), occasionally the installation does not complete because, it seems, Windows locks some files.
2020 Mar 23
0
Inconsistant result for normalizePath on Windows
Hi Jiefei, the change in handling trailing path separators is not on purpose, but is a byproduct of a new implementation of normalizePath, which now handles symbolic links and normalizes case in long path names. It is not documented what happens to trailing separators, and hence portable programs should not depend on it. I don't think it is a property that should be documented/specified.
2009 Apr 11
0
_Possible_ work-round for normalizePath error (was Re: [Rd] Package (PR#13475))
>>> Uwe Ligges <ligges at statistik.tu-dortmund.de> 04/10/09 4:21 PM >>> >Well, you need to ask Symantec to fix Norton, hence this is the >wrong address. That would not help other R users who were looking in the archives for help with what looked like a mysterious normalizePath error, would it? As I said, the principal intent of the posting was to point to a
2020 Apr 15
0
Suggestion/opinions: add a `absolute` param to `normalizePath()` to force returning an absolute path
The fs[1] function `fs::path_abs()` does what I believe you were expecting `normalizePath()` to do in this case. e.g. setwd("~") normalizePath("foo/bar") #> Warning in normalizePath("foo/bar") : #> path[1]="foo/bar": No such file or directory #> [1] "foo/bar" fs::path_abs("foo/bar") #>
2016 Nov 30
0
problem with normalizePath()
In researching another issue, I discovered a workaround: the network drive folder needs to be mapped to the local PC. setwd("//Hzndhhsvf2/data/OCPH/EPI/BHSDM/Group/Michael Laviolette/Stat tools") df1 <- readxl::read_excel("addrlist-4-MikeL.xls", 2) # fails, throws same error df2 <- readxl::read_excel("Z:/Stat
2016 Nov 17
0
problem with normalizePath()
I wonder if this could be related to the issue that I submitted to bugzilla about two months ago? ( https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=17159) That is to say, could it be that it's treating the first path after the single backslash as an actual directory, rather than as the name of the share? -- Evan Cortens, PhD Institutional Analyst - Office of Institutional Analysis
2020 Apr 14
0
Suggestion/opinions: add a `absolute` param to `normalizePath()` to force returning an absolute path
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