Re: [Rd] How best to get around shadowing of executables by system()'s prepending of directories to Windows' PATH?
You probably already know, but you can at least work around it as:
Sys.which2 <- function(cmd) {
stopifnot(length(cmd) == 1)
if (.Platform$OS.type == "windows") {
suppressWarnings({
pathname <- shell(sprintf("where %s 2> NUL", cmd), intern=TRUE)[1]
})
if (!is.na(pathname)) return(setNames(pathname, cmd))
}
Sys.which(cmd)
}
(it falls back to Sys.which() if 'where %s' doesn't give anything)
> Sys.which2("convert")
convert
"C:\\Program Files\\ImageMagick-6.8.3-Q16\\convert.exe"
> Sys.which("convert")
convert
"C:\\Windows\\system32\\convert.exe"
/Henrik
On Mon, May 18, 2015 at 11:08 AM, Yihui Xie wrote:
> +1 I have exactly the same problem.
>
> Regards,
> Yihui
> --
> Yihui Xie
> Web: http://yihui.name
>
>
> On Mon, May 18, 2015 at 12:29 PM, Josh O'Brien wrote:
>> My question:
>>
>> On Windows, R's system() command prepends several directories to those
>> in the Windows Path variable.
>>
>> >From ?system
>>
>> The search path for 'command' may be system-dependent: it will
>> include the R 'bin' directory, the working directory and the
>> Windows system directories before 'PATH'.
>>
>> This shadows any executables on the Path that share a name with, for
>> example, one of the Windows commands.
>>
>> What should I do when I'd really like (the equivalent of) a call
>> passed to system() that would be executed using the same Path that
>> you'd get if working directly at the Windows command line? Is there a
>> recommended workaround for situtations like this? (It _seems_ like it
>> would be handy if system() et al. included an additional argument that
>> optionally disabled the prepending of those extra directories, to give
>> Windows users full control of the path seen by system(). Would adding
>> such an argument have undesirable ramifications?)
>>
>>
>> Motivation and reproducible example:
>>
>> I'm motivated here by a desire to use the function plotdiff() from
>> Paul Murrell's gridGraphics package on my Windows laptop. Getting
>> that to work will require a few code fixes, of which the masking of
>> ImageMagick's convert.exe by that in the C:/Windows/System32 seems to
>> be the most challenging. plotdiff() relies on system2() calls to
>> ImageMagick's 'convert' function, as well as a call to
>> Sys.which(c("convert", "compare")) that tests for the presence of
>> ImageMagick on the Path. Even if ImageMagick is placed early on the
>> Path, though, both calls to Sys.which() and system2() find Windows'
>> convert command (which "Converts FAT volumes to NTFS") rather than
>> ImageMagick's convert.
>>
>>
>> Here's a reproducible example that shows what I'm seeing:
>>
>> ## In R, make a pdf
>> pdf("a.pdf")
>> plot(rnorm(99), col="red")
>> dev.off()
>>
>> ## At Windows cmd command line
>> where convert
>> ## C:\Program Files\ImageMagick-6.8.8-Q16\convert.exe
>> ## C:\Windows\System32\convert.exe
>> convert -density 100x100 a.pdf a.png
>>
>> ## From R
>>
>> ## Unqualified references to convert find the 'wrong' one
>> Sys.which("convert")
>> ## convert
>> ## "C:\\Windows\\system32\\convert.exe"
>> system2("convert", "-density 100x100 a.pdf b.png")
>> ## Invalid Parameter - 100x100
>> ## Warning message:
>> ## running command '"convert" -density 100x100 a.pdf b.png' had status 4
>>
>> ## A fully qualified reference does work
>> system2("C:/Program Files/ImageMagick-6.8.8-Q16/convert",
>> "-density 100x100 a.pdf b.png")
>>
>> __
>> 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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] \alias{} --> rather \concept{} for conceptual "links" to help pages
Hi Martin,
On 05/18/2015 05:14 AM, Martin Maechler wrote:
From R-help, subject "Variable number of loops"
I've opened a new thread, moving from R-help to R-devel ..
Jim Lemon
on Sun, 17 May 2015 09:19:06 +1000 writes:
> Hi all, Given the number of help requests that involve
> permutations/combinations, and the less than obvious
> naming of the expand.grid function, perhaps adding an
> alias such as "permute.elements" or "combine.elements"
> might ease the tasks of both searchers and those offering
> help. Neither of the above names appear to be used at
> present.
> Jim
Using \alias{} is not a very good thing here, since as you know they
are *key*s that must remain unique if possible and they can be
linked to -- which I think would not be helpful for 'expand.grid'.
It seems to me that Jim was maybe suggesting to define an alias for the
expand.grid function i.e. something like:
permute.elements <- expand.grid
or
combine.elements <- expand.grid
as a way to address the "less than obvious naming of the expand.grid
function". But maybe I misunderstood...
Cheers,
H.
Rather, for quite a few years now, we have had \concept{} for
adding "search keywords", i.e., things that
help.search() and hence ?? will find.
The other advantage of \concept{} is that you can use short
phrases, i.e.,
\concept{all variable combinations}
would be possible here.
(Better wording proposals for this specific case are welcome! --
maybe privately).
Martin Maechler, ETH Zurich
> On Sun, May 17, 2015 at 5:54 AM, Bert Gunter
> wrote:
>> 1. Please always reply to the list unless there is a
>> compelling reason to keep the discussion private. You
>> will have a better chance of getting something useful
>> that way.
>>
>> 2. I don't know what you mean by "I don't have a fixed
>> number of variables." You have to specify at least the
>> number of variables and how many levels each has in order
>> to work out what you requested, which is **NOT** the
>> number of permutations but the number of combinations
>> AFAICS, which is exactly what expand.grid will give you.
>>
>> 3. Maybe what you're looking for is the ... arguments in
>> function calls, which would be used along the lines of:
>>
>> myfun <- function( x,y,...) { ## some code combs <-
>> expand.grid(...) ## some more code }
>>
>> Any good R tutorial will tell you about this if this is
>> unfamiliar.
>>
>> 4. Another possibility might be to deliver a list of
>> named variables as an argument and then use do.call, e.g.
>>
>> myfun <- (x,y, alist) { ## some code combs <-
>> do.call(expand.grid, alist) ## some more code }
>>
>> ?do.call and/or a tutorial for details.
>>
>> 5. Otherwise, maybe someone else can figure out what
>> you're looking for.
>>
>> Cheers, Bert
>>
>>
>>
>> Bert Gunter Genentech Nonclinical Biostatistics (650)
>> 467-7374
>>
>> "Data is not information. Information is not
>> knowledge. And knowledge is certainly not wisdom."
>> Clifford Stoll
>>
>>
>>
>>
>> On Sat, May 16, 2015 at 11:16 AM, WRAY NICHOLAS
>> wrote:
>>> I might be but doesn't expand.grid need a defined and
>>> listed number of inputs? The problem I'm having is that
>>> the number of variables is not fixed, so I'm not sure
>>> whether I can reference the variable number of variables
>>> by using a vector -- haven't had time to try yet But
>>> thanks anyway Nick Wray
>>>
>>> On 16 May 2015 at 14:28, Bert Gunter
>>> wrote:
Are you trying to reinvent ?expand.grid ?
-- Bert
Bert Gunter Genentech Nonclinical Biostatistics (650)
467-7374
"Data is not information. Information is not
knowledge. And knowledge is certainly not wisdom."
Clifford Stoll
[...]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fredhutch.org
Phone: (206) 667-5791
Fax:(206) 667-1319
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] A "bug" in plot.dendrogram - can't plot lty with character color
The problem:
===
Once a dendrogram has a branch with both a line type AND a color (which is
a character color), the plot.dendrogram function will not plot and return
an error.
I say this is a bug because (I believe), we would like a dendrogram to be
able to use character colors, while also allowing control over line types.
This e-mail includes an example, and what I think a solution might be.
Reproducible example:
=
install.packages('dendextend')
library('dendextend')
dend <- 1:2 %>% dist %>% hclust %>% as.dendrogram
plot(dend) # works fine
dend %>% set("branches_lty", 1:2) %>% plot # works fine
dend %>% set("branches_col", 1:2) %>% plot # works fine
dend %>% set("branches_col", as.character(1:2)) %>% plot # works fine
# Fails:
dend %>% set("branches_lty", 1:2) %>% set("branches_col",
as.character(1:2)) %>% plot
### Error:
# Error in segments(x0, y0, x1, y1, col = col, lty = lty, lwd = lwd) :
#invalid line type: must be length 2, 4, 6 or 8
# This is because edgePar has to hold both "lty" and "col"
# Since "col" is a character, it forces "lty" to become a character also.
dend %>% set("branches_lty", 1:2) %>% set("branches_col",
as.character(1:2)) %>%
unclass %>% str
Possible solution
==
The simplest (and backward) compatible solution I can think of is to edit
the function:
stats:::plotNode
And change the following lines:
col <- Xtract("col", ePar, default = par("col"),
i)
lty <- Xtract("lty", ePar, default = par("lty"),
i)
lwd <- Xtract("lwd", ePar, default = par("lwd"),
i)
With:
col <- Xtract("col", ePar, default = par("col"),
i)
lty <- as.numeric(Xtract("lty", ePar, default = par("lty"),
i))
lwd <- as.numeric(Xtract("lwd", ePar, default = par("lwd"),
i))
With regards,
Tal
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How best to get around shadowing of executables by system()'s prepending of directories to Windows' PATH?
+1 I have exactly the same problem.
Regards,
Yihui
--
Yihui Xie
Web: http://yihui.name
On Mon, May 18, 2015 at 12:29 PM, Josh O'Brien wrote:
> My question:
>
> On Windows, R's system() command prepends several directories to those
> in the Windows Path variable.
>
> >From ?system
>
> The search path for 'command' may be system-dependent: it will
> include the R 'bin' directory, the working directory and the
> Windows system directories before 'PATH'.
>
> This shadows any executables on the Path that share a name with, for
> example, one of the Windows commands.
>
> What should I do when I'd really like (the equivalent of) a call
> passed to system() that would be executed using the same Path that
> you'd get if working directly at the Windows command line? Is there a
> recommended workaround for situtations like this? (It _seems_ like it
> would be handy if system() et al. included an additional argument that
> optionally disabled the prepending of those extra directories, to give
> Windows users full control of the path seen by system(). Would adding
> such an argument have undesirable ramifications?)
>
>
> Motivation and reproducible example:
>
> I'm motivated here by a desire to use the function plotdiff() from
> Paul Murrell's gridGraphics package on my Windows laptop. Getting
> that to work will require a few code fixes, of which the masking of
> ImageMagick's convert.exe by that in the C:/Windows/System32 seems to
> be the most challenging. plotdiff() relies on system2() calls to
> ImageMagick's 'convert' function, as well as a call to
> Sys.which(c("convert", "compare")) that tests for the presence of
> ImageMagick on the Path. Even if ImageMagick is placed early on the
> Path, though, both calls to Sys.which() and system2() find Windows'
> convert command (which "Converts FAT volumes to NTFS") rather than
> ImageMagick's convert.
>
>
> Here's a reproducible example that shows what I'm seeing:
>
> ## In R, make a pdf
> pdf("a.pdf")
> plot(rnorm(99), col="red")
> dev.off()
>
> ## At Windows cmd command line
> where convert
> ## C:\Program Files\ImageMagick-6.8.8-Q16\convert.exe
> ## C:\Windows\System32\convert.exe
> convert -density 100x100 a.pdf a.png
>
> ## From R
>
> ## Unqualified references to convert find the 'wrong' one
> Sys.which("convert")
> ## convert
> ## "C:\\Windows\\system32\\convert.exe"
> system2("convert", "-density 100x100 a.pdf b.png")
> ## Invalid Parameter - 100x100
> ## Warning message:
> ## running command '"convert" -density 100x100 a.pdf b.png' had status 4
>
> ## A fully qualified reference does work
> system2("C:/Program Files/ImageMagick-6.8.8-Q16/convert",
> "-density 100x100 a.pdf b.png")
>
> __
> 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
[Rd] How best to get around shadowing of executables by system()'s prepending of directories to Windows' PATH?
My question:
On Windows, R's system() command prepends several directories to those
in the Windows Path variable.
>From ?system
The search path for 'command' may be system-dependent: it will
include the R 'bin' directory, the working directory and the
Windows system directories before 'PATH'.
This shadows any executables on the Path that share a name with, for
example, one of the Windows commands.
What should I do when I'd really like (the equivalent of) a call
passed to system() that would be executed using the same Path that
you'd get if working directly at the Windows command line? Is there a
recommended workaround for situtations like this? (It _seems_ like it
would be handy if system() et al. included an additional argument that
optionally disabled the prepending of those extra directories, to give
Windows users full control of the path seen by system(). Would adding
such an argument have undesirable ramifications?)
Motivation and reproducible example:
I'm motivated here by a desire to use the function plotdiff() from
Paul Murrell's gridGraphics package on my Windows laptop. Getting
that to work will require a few code fixes, of which the masking of
ImageMagick's convert.exe by that in the C:/Windows/System32 seems to
be the most challenging. plotdiff() relies on system2() calls to
ImageMagick's 'convert' function, as well as a call to
Sys.which(c("convert", "compare")) that tests for the presence of
ImageMagick on the Path. Even if ImageMagick is placed early on the
Path, though, both calls to Sys.which() and system2() find Windows'
convert command (which "Converts FAT volumes to NTFS") rather than
ImageMagick's convert.
Here's a reproducible example that shows what I'm seeing:
## In R, make a pdf
pdf("a.pdf")
plot(rnorm(99), col="red")
dev.off()
## At Windows cmd command line
where convert
## C:\Program Files\ImageMagick-6.8.8-Q16\convert.exe
## C:\Windows\System32\convert.exe
convert -density 100x100 a.pdf a.png
## From R
## Unqualified references to convert find the 'wrong' one
Sys.which("convert")
## convert
## "C:\\Windows\\system32\\convert.exe"
system2("convert", "-density 100x100 a.pdf b.png")
## Invalid Parameter - 100x100
## Warning message:
## running command '"convert" -density 100x100 a.pdf b.png' had status 4
## A fully qualified reference does work
system2("C:/Program Files/ImageMagick-6.8.8-Q16/convert",
"-density 100x100 a.pdf b.png")
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] \alias{} --> rather \concept{} for conceptual "links" to help pages
>From R-help, subject "Variable number of loops"
I've opened a new thread, moving from R-help to R-devel ..
> Jim Lemon
> on Sun, 17 May 2015 09:19:06 +1000 writes:
> Hi all, Given the number of help requests that involve
> permutations/combinations, and the less than obvious
> naming of the expand.grid function, perhaps adding an
> alias such as "permute.elements" or "combine.elements"
> might ease the tasks of both searchers and those offering
> help. Neither of the above names appear to be used at
> present.
> Jim
Using \alias{} is not a very good thing here, since as you know they
are *key*s that must remain unique if possible and they can be
linked to -- which I think would not be helpful for 'expand.grid'.
Rather, for quite a few years now, we have had \concept{} for
adding "search keywords", i.e., things that
help.search() and hence ?? will find.
The other advantage of \concept{} is that you can use short
phrases, i.e.,
\concept{all variable combinations}
would be possible here.
(Better wording proposals for this specific case are welcome! --
maybe privately).
Martin Maechler, ETH Zurich
> On Sun, May 17, 2015 at 5:54 AM, Bert Gunter
> wrote:
>> 1. Please always reply to the list unless there is a
>> compelling reason to keep the discussion private. You
>> will have a better chance of getting something useful
>> that way.
>>
>> 2. I don't know what you mean by "I don't have a fixed
>> number of variables." You have to specify at least the
>> number of variables and how many levels each has in order
>> to work out what you requested, which is **NOT** the
>> number of permutations but the number of combinations
>> AFAICS, which is exactly what expand.grid will give you.
>>
>> 3. Maybe what you're looking for is the ... arguments in
>> function calls, which would be used along the lines of:
>>
>> myfun <- function( x,y,...) { ## some code combs <-
>> expand.grid(...) ## some more code }
>>
>> Any good R tutorial will tell you about this if this is
>> unfamiliar.
>>
>> 4. Another possibility might be to deliver a list of
>> named variables as an argument and then use do.call, e.g.
>>
>> myfun <- (x,y, alist) { ## some code combs <-
>> do.call(expand.grid, alist) ## some more code }
>>
>> ?do.call and/or a tutorial for details.
>>
>> 5. Otherwise, maybe someone else can figure out what
>> you're looking for.
>>
>> Cheers, Bert
>>
>>
>>
>> Bert Gunter Genentech Nonclinical Biostatistics (650)
>> 467-7374
>>
>> "Data is not information. Information is not
>> knowledge. And knowledge is certainly not wisdom."
>> Clifford Stoll
>>
>>
>>
>>
>> On Sat, May 16, 2015 at 11:16 AM, WRAY NICHOLAS
>> wrote:
>>> I might be but doesn't expand.grid need a defined and
>>> listed number of inputs? The problem I'm having is that
>>> the number of variables is not fixed, so I'm not sure
>>> whether I can reference the variable number of variables
>>> by using a vector -- haven't had time to try yet But
>>> thanks anyway Nick Wray
>>>
>>> On 16 May 2015 at 14:28, Bert Gunter
>>> wrote:
Are you trying to reinvent ?expand.grid ?
-- Bert
Bert Gunter Genentech Nonclinical Biostatistics (650)
467-7374
"Data is not information. Information is not
knowledge. And knowledge is certainly not wisdom."
Clifford Stoll
[...]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
