Displaying 20 results from an estimated 1000 matches similar to: "Suggestion/opinions: add a `absolute` param to `normalizePath()` to force returning an absolute path"
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")
#>
Suggestion/opinions: add a `absolute` param to `normalizePath()` to force returning an absolute path
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\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