similar to: system2() shortens R.home() to 8.3 form on windows

Hello, I have come across two separate packages that have a Makefile in inst/doc which use the R_HOME variable. In both cases, the path to R_HOME gets munged in such a way that commands that include R_HOME fail on Windows: For example, one Makefile, for the xmapcore package ( https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks/xmapcore/username/password: readonly) has this:

Hi, Every day a few Bioconductor packages (different ones each day) fail to build, on Windows only, with an error like this: D:\biocbld\bbs-2.13-bioc\meat>D:\biocbld\bbs-2.13-bioc\R\bin\R.exe CMD build --keep-empty-dirs --no-resave-data OrganismDbi [...] Error in find_vignette_product(name, by = "texi2pdf", engine = engine) : Failed to locate the 'texi2pdf' output file (by

Just thought I would mention that the issue below (and in https://stat.ethz.ch/pipermail/r-devel/2013-April/066318.html) is still not resolved. It hasn't been a big problem, but it potentially could be, if a critical package were to have this error on release day, then all its dependencies would fail to build, which would probably require us to postpone our release. See the complete thread

Hello, I'm seeing three different vignette-related errors with recent versions of R-3.0.0 alpha. First, with the package BitSeq (http://bioconductor.org/packages/2.12/bioc/html/BitSeq.html), I get the following when trying to build the package: Error: processing vignette ?BitSeq.Rnw' failed with diagnostics: Failed to locate the ?weave? output file (by engine ?utils::Sweave?) for

Hi, Why isn't 'R CMD check --force-multiarch' installing the package for all the architectures that are going to be checked? For some packages, it only installs for the default arch ('i386'). Then testing the package for 'x64' fails. For example, Output of R CMD check --force-multiarch fabia_1.5.0.tar.gz: ----------------------------------------------------------- *

Hi, On both Unix and Windows there is a mechanism to add variables to the environment when R is started. I noticed that, on Unix, this mechanism is not used when R is started normally at the command line but only when it's started using the 'R CMD' syntax. One problem with this is some lack of consistent cross-platform behaviour. For example: On Linux: $ echo $TEXINPUTS $

I am having a problem using two DLLs with the same name, but obviously located in different directories, in an R session. The troublesome package is the (Bioconductor) Rgraphviz package. It relies on (3rd party software) graphviz and imports functions from (Bioconductor) package graph. Unfortunately, the current stable release of graphviz for Windows

Hi, This is a follow up to: https://stat.ethz.ch/pipermail/r-devel/2010-July/057921.html The Bioconductor daily builds have been reporting a lot of strange things lately on Windows using R-2.12. This started 2 or 3 months ago and things are not getting better with recent R-2.12. Here is a sample from today's build results. We use Windows Server 2003 R2 for the 32-bit builds, Windows

Hi, The R-based version of R CMD build doesn't work for me on Windows: E:\biocbld\bbs-2.7-bioc>R\bin\R CMD build meat\Biobase * checking for file 'meat\Biobase/DESCRIPTION' ... OK * preparing 'Biobase': * checking DESCRIPTION meta-information ... OK * cleaning src * installing the package to re-build vignettes Warning in shell(sprintf("%s > %s

Hi, 'R CMD build' (with R 2.12.0 RC) fails to clean the src/ folder on Windows: D:\biocbld\bbs-2.7-bioc>ls meat/BUS/src BUS.cpp BUS.h D:\biocbld\bbs-2.7-bioc>R\bin\R CMD build meat\BUS * checking for file 'meat\BUS/DESCRIPTION' ... OK * preparing 'BUS': * checking DESCRIPTION meta-information ... OK * cleaning src * installing the package

According to ?system2, I should be able to direct the output of STDERR to a file by giving the filename as a character vector to the "stderr" argument. But here is what happens. Given a ruby script test.rb (with its executable bit set): #!/usr/bin/env ruby STDOUT.puts "stdout" STDERR.puts "stderr" And the following R code: > t <- tempfile() > res <-

In the process of updating R to R 2.7 alpha or R 2.7 beta for the BioConductor 2.2 builds on Windows, I have hit a snag because the BioC build system has long path names (e.g. D:\biocbld\bbs-2.2-bioc\R) and these path names are not resolving properly by MiKTeX 2.7 during vignette construction. Take, for example, the attached vignette from Biobase, Bioconductor.Rnw. I have built R from source

Hi, Installing from binaries on Windows: > install.packages("multtest") Warning: dependency 'Biobase' is not available trying URL 'http://cran.fhcrc.org/bin/windows/contrib/2.12/multtest_2.6.0.zip' Content type 'application/zip' length 1645590 bytes (1.6 Mb) opened URL downloaded 1.6 Mb package 'multtest' successfully unpacked

We are trying to setup a Windows server that will allow any of our users to build a binary R package given a source package. The idea is to have a central R installation and allow users to install packages to their own package library for the purposes of binary package building. It seems, however, that write access to $R_HOME is required as part of the install step even when -l is used to

Hi, On Windows, with last R-devel tarball (r40647) from ftp://ftp.stat.math.ethz.ch/Software/R/R-devel_2007-02-04.tar.gz I get the following build error: E:\biocbld\bbs-2.0-bioc\R\src\gnuwin32> make ... ... ---------- Making package utils ------------ adding build stamp to DESCRIPTION installing NAMESPACE file and metadata installing R files Error in namespaceExport(ns, exports) :

FWIW I can reproduce on macOS with R 3.5.1. A smaller example: system2("ls", timeout = 5); x <- sample(1:1E8) If I try to interrupt R while that sample call is running, R itself is closed. Best, Kevin On Fri, Sep 14, 2018 at 10:53 AM Emil Bode <emil.bode at dans.knaw.nl> wrote: > > I hope it's not too specific in my setup... > I've tried with system2

Hi, I have recently tried to check the test coverage using library("covr") and, interestingly, the command > covr::package_coverage() fails, while > covr::package_coverage(quiet = FALSE) runs through without problem. I traced the problem to a call to utils::install.packages(), where the option quiet is passed on. In utils::install.packages(), the problem seems to lie in the

You are using it wrong. It wants strings of the form "name=value", not a character vector with names as labels. So this is closer to the mark: > system2("echo", env = c("VAR='Hello World'"), args = c("$VAR")) > However, as you see it doesn't work as intended. The problem is that the $-substitution refers to the environment of the shell

On Windows, ?env? is only supported for commands such as ?R? and ?make? which accept environment variables on their command line. So I suppose that would be tricky. The basic issue is that on Unix-alikes, system2 constructs a command like FOO=bar cmd args and passes that to sh via system(). On windoes, system() does not call sh, so system2() does (effectively) cmd FOO=bar args and

I can't reproduce this. Can you be more precise: exactly where are you putting the system2 call and exactly where are you sending the interrupt signal with ^C? Best, luke On Fri, 14 Sep 2018, Emil Bode wrote: > Hi all, > > I found some strange behaviour, which I think is a bug. Could someone make an account for me on Bugzilla or pass on my report? > > The problem: > When