similar to: system2 fails with quiet=TRUE, but runs through with quiet=FALSE

Just noticed that this problem only occurs from within RStudio (v1.1.414). Any ideas why? Am 26.01.2018 um 08:56 schrieb Andreas Kersting: > Hi, > > Installing a source package on Windows using utils::install.packages() > with quiet=TRUE fails, while it works with the default quiet = FALSE. > The problem seems to be caused by the fact that when quiet = TRUE, > stdout and

The obvious guess would be that Rstudio is attempting something like redirecting output and getting itself confused. However, it is pretty clearly Their Problem, no? Rstudio has their own support infrastructure. -pd > On 26 Jan 2018, at 09:17 , Andreas Kersting <r-devel at akersting.de> wrote: > > Just noticed that this problem only occurs from within RStudio (v1.1.414). Any

Hi, Installing a source package on Windows using utils::install.packages() with quiet=TRUE fails, while it works with the default quiet = FALSE. The problem seems to be caused by the fact that when quiet = TRUE, stdout and stderr are set to FALSE when calling "R CMD INSTALL" with base::system2() here:

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 <-

Is there any way to capture output (both stdout and stderr) from install.packages? Solutions like sink and capture.output don't work because the install.packages calls out to system2 which is executed in a separate process: test <- capture.output(install.packages("MASS")) The system2 function does have arguments stdout and stderr but afaik these cannot be controlled via

Hi again! While investigating the bug report [*] I found out that on unix, system2 does not quote its `stdin` argument while preparing the command line to launch. It does shQuote the `stdout` and `stderr` arguments, and also the `f <- tmpfile()` variable (which is used if `input` argument is provided), which seems to set a precedent. On Windows, stdin, stdout, and stderr are handled

According to the manual, the `stdout` argument of the `system2` function can redirect output to a file. This seems to work on unix, however I can't get it to work on windows. The toy example below, no `out.txt` or `err.txt` files are created. I tried sending it to an existing file, or expand the full file path, but with no success: setwd(tempdir()) system2("whoami",

Second this. As the CRAN Policies suggests, there's also the very handy winbuilder service (https://win-builder.r-project.org/) you can use to check your package on Windows. This service has been a valuable workhorse for years. We should also mention the continuous integration (CI) services provided for free by Travis (Linux and macOS) and AppVeyor (Windows) in combination with GitHub (or

withr:::set_makevars() can give that error if the makefile named by the 'old_path' argument (default "~/.R/Makevars) contains more than one definition of a variable of the form 'name=value'. You can see what file it is reading and its contents by using the trace() function: trace(withr:::set_makevars, quote({ cat(old_path, "\n"); writeLines(paste0(" ",

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, So in an interactive R session, R.home() returns the following: > R.home() [1] "D:/biocbld/bbs-3.2-bioc/R" However, if I call it from system2(), I get different results: > system2("R", "-q -e R.home()") > R.home() [1] "D:/biocbld/BBS-3~1.2-B/R" Similarly: > system2("R", "-q -e Sys.getenv('R_HOME')") >

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

Hi All; This problem has come about from trying to learn some of the review practices recommend by rOpensci. One of them is to use the package goodpractice. After installing goodpractice, it kept failing on my own packages which are under development, and I was concerned something was funny in my own , so I have a fork of the package rerddap, and I tested goodpractice on that. I get the

On Tue, Mar 19, 2019 at 9:59 AM peter dalgaard <pdalgd at gmail.com> wrote: [...] > What you need is something like (NB: single quotes!) > > system2("sh", env = c("VAR='Hello World'"), args = c("-c 'echo $VAR'")) > Hello World Just out of curiosity, do you think it is possible to make this portable, assuming sh is available? On

In addition to the issue of a child process holding onto open files, the child process can also manipulate a file descriptor in a way that affects the parent process. For example, calling lseek() in the child process will move the file offset in the parent process. Here is a set of commands that demonstrates it. They can be copied and pasted in a terminal. What it does: - Creates C program that

I hope it's not too specific in my setup... I've tried with system2 added on the first line, so: Example.R: system2('ls', timeout=5) cat('Start non-interruptable functions\n') sample_a <- sample(1:1e7) sample_b <- sample(1:2e7) matching <- match(sample_a, sample_b) cat('Finished\n') Sys.sleep(10) And in terminal/bash: R --vanilla

Hello, I help to maintain a moderate library of R code. In this code we have a number of calls to the system function along the lines of: exe_output = system("./executable.exe",intern=T) We tend to prefer system() over shell() because, provided the executable has been compiled and the working directory set, the command works under both linux and windows. We've never had a

Hey all, what is wrong with this command: system2("echo", env = c(VAR = "Hello World"), args = c("$VAR")) I am a bit confused, as help("system2") writes about the env option: > character vector of name=value strings to set environment variables. Is this option buggy, or am I using it just wrong? Thanks for your help Henning