similar to: Suggestion/opinions: add a `absolute` param to `normalizePath()` to force returning an absolute path

Displaying 20 results from an estimated 1000 matches similar to: "Suggestion/opinions: add a `absolute` param to `normalizePath()` to force returning an absolute path"

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") #>
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
2018 Jun 29
1
Bug in tools::md5sum - does not work when filepath contains tilde (ie home directory)
I've reproduced on ubuntu and winodws with R3.4.3 When the filepath contains a tilde, the result is NA. But if the file path is expanded then the function works. Example: tools::md5sum("~/.Rprofile") returns NA tools::md5sum(normalizePath("~/.Rprofile")) returns the proper md5 Perhaps this is expected behaviour because the documentation does say NA is returned for
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.
2019 Feb 20
2
Bug in print.default: dispatches to global show instead of methods::show
This is related to a problem that was fixed in 2015 https://github.com/wch/r-source/commit/38ea40dcd0353af16d35296ee621338c49ae48c9 The problem then was that auto-printing by typing an object to the console would search for show() in the globalenv instead of in the methods namespace. The problem I would like to report is that it seems that when an S4 object is printed with print(), a similar
2015 Jun 30
2
Defining a `show` function breaks the print-ing of S4 object -- bug or expected?
Hi r-devel If you define a function named `show` or attach a package with an exported `show` function, then printing/vieweing S4 objects breaks. This is probably because the `print` function calls `show`, which is now masked. Example: show <- function() {} > setClass("Person", slots = list(name = "character")) > tom <- new("Person", name =
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
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
2011 Sep 14
3
normalizePath
Hi, I update R from 2.10 to 2.13. Then I find soma problems when I start R. Warning infos as below: ##### Warning message: In normalizePath(c(new, .Library.site, .Library), "/") : path[1]="": No such file or directory R version 2.13.1 (2011-07-08) Copyright (C) 2011 The R Foundation for Statistical Computing ISBN 3-900051-07-0 Platform: x86_64-pc-linux-gnu (64-bit) R is
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
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]
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
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
2015 Jul 08
5
Graphical User Interface (GUI)
I'd like to create a user interface for my R code and have only seen mostly older posts on the subject. I'm not looking for an IDE for development, but something that the end user of the software would use. So something that would involve displaying buttons, listboxes, and drop down menus to a user that will facilitate various actions. I doubt there is anything Visual Studio-like that
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