I know the function has an quiet
argument, but I'm trying to suppress the message when quiet = FALSE
.
This may be weird, but I came across this issue when testing a package I'm writing. I'm using testthat::expect_message()
when setting quiet = FALSE
, but the function is not actually suppressing the message (it should, and in fact it usually does with "normal" messages).
I tried it with suppressMessages()
, but it didn't work as expected:
url <- "https://github.com/ipeaGIT/gtfstools/raw/master/inst/extdata/spo_gtfs.zip"
download.file(url, destfile = tempfile(), quiet = FALSE)
#> trying URL 'https://github.com/ipeaGIT/gtfstools/raw/master/inst/extdata/spo_gtfs.zip'
#> Content type 'application/zip' length 191108 bytes (186 KB)
#> downloaded 186 KB
suppressMessages(download.file(url, destfile = tempfile(), quiet = FALSE))
#> trying URL 'https://github.com/ipeaGIT/gtfstools/raw/master/inst/extdata/spo_gtfs.zip'
#> Content type 'application/zip' length 191108 bytes (186 KB)
#> downloaded 186 KB
Any ideas on how to suppress it, preferably without changing any options
? It's not a lifethreatening situation, but it is making me curious.
suppressMessages()
doesn't work because the progress text isn't an R message()
, it's the stdout of the the system library that download.file()
delegates the actual downloading to (e.g. libcurl
, wget
or wininet
). quiet = TRUE
bypasses this by setting the appropriate command line option of that tool.
You can divert stdout from the R console to a file with sink()
. Since you don't need it, you can use nullfile()
to open a file connection to the platform-dependent null device:
url <- "https://github.com/ipeaGIT/gtfstools/raw/master/inst/extdata/spo_gtfs.zip"
nullcon <- file(nullfile(), open = "wb")
sink(nullcon, type = "message")
download.file(url, destfile = tempfile(), quiet = FALSE)
sink(type = "message")
close(nullcon)
Note that the second-to-last line is very important – it ends the diversion. Without it, all further messages in the R session will be sent to /dev/null
.
Also bear in mind the following warnings from ?sink
:
Do not use a connection that is open for sink for any other purpose. The software will stop you closing one such inadvertently.
Do not sink the messages stream unless you understand the source code implementing it and hence the pitfalls.
Personally I'd say this method is too risky to use in a package, especially when the quiet = TRUE
option is available.