similar to: Capture output of install.packages (pipe system2)

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

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

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

Dear list, I'm trying to suppress/redirect/squash the output from commands like install.packages, or download.file. The problem is that none of: sink(..., type="message"), sink(..., type="output"), capture.output, suppressMessages are quite doing the trick. Output gets written to the stderr stream, despite any combination of the above suppression commands. According to

As far as I can tell, there's no built-in way to get capture.output() to capture messages (stderr) instead of stdout ... suggested, fairly trivial, patch below. f <- function() { message("abc") cat("def\n") } x <- capture.output(f()) ## prints 'abc' x ## value: "def" source("~/R/r-devel/src/library/utils/R/capture.output.R") x

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

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:

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

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

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

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 pressing Ctrl-C when a file is sourced in R, run from Terminal (macOS), sometimes the entire session is ended right away, while I just want to stop the script. This is the case when I press Ctrl-C while some functions are running that don?t

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

In R, there's readline(), which is great because you can prompt the user, e.g. ans <- readline("Would you like to install Pandoc? [y/N]: ") without having to worry the message is intercepted by capture.output(), sink() or similar (which is used by dynamic report generators among other things). The message will always reach the user. (You can use sink(...,

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

It seems that the system() and system2() functions don't close file descriptors between the fork() and exec() (on Unix platforms, of course). This means that the child processes inherit open files and socket connections. Running this (from a terminal) will result in the child process writing to a file that was opened by R: R f <- file('foo.txt', 'w') system('echo

A user has reported an issue that appears when a fortran executable is called via R on Windows. I am unsure if this expected behavior or a bug in Fortran or in how R calls Windows executables. The problem is that when the fortran program is called from R, stdout gets written to a file "fort.6" instead of stdout. When the same executable is called from the terminal it works fine and

On 31/10/2023 4:32 a.m., Tomas Kalibera wrote: > > On 10/30/23 19:07, Yihui Xie wrote: >> Sure. I'm not sure if it's possible to make it easier to reproduce, >> but for now the example would require installing TinyTeX (via >> tinytex::install_tinytex(), which can be later uninstalled cleanly via >> tinytex::uninstall_tinytex() after you finish the

Sure. I'm not sure if it's possible to make it easier to reproduce, but for now the example would require installing TinyTeX (via tinytex::install_tinytex(), which can be later uninstalled cleanly via tinytex::uninstall_tinytex() after you finish the investigation). Then run: system2('fmtutil-sys', '--all') # or tinytex:::fmtutil() if fmtutil-sys.exe is not on PATH

On 10/30/23 19:07, Yihui Xie wrote: > Sure. I'm not sure if it's possible to make it easier to reproduce, > but for now the example would require installing TinyTeX (via > tinytex::install_tinytex(), which can be later uninstalled cleanly via > tinytex::uninstall_tinytex() after you finish the investigation). Then > run: > > ? system2('fmtutil-sys',

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