systeminvokes the OS command specified by
system(command, intern = FALSE, ignore.stdout = FALSE, ignore.stderr = FALSE, wait = TRUE, input = NULL, show.output.on.console = TRUE, minimized = FALSE, invisible = TRUE)
NA) which indicates whether to capture the output of the command as an R character vector.
NA) indicating whether messages written to
stderrshould be ignored.
NA) indicating whether the R interpreter should wait for the command to finish, or run it asynchronously. This will be ignored (and the interpreter will always wait) if
intern = TRUE.
commandis redirected to the file.
NA), indicates whether to capture the output of the command and show it on the R console (not used by
Rterm, which shows the output in the terminal unless
NA), indicates whether a command window should be displayed initially as a minimized window.
NA), indicates whether a command window should be visible on the screen.
intern = TRUE, a character vector giving the output of the command, one line per character string. (Output lines of more than 8095 bytes will be split.) If the command could not be run an R error is generated. Under the
intern = TRUEalso captures
ignore.stderr = TRUE. If
commandruns but gives a non-zero exit status this will be reported with a warning and in the attribute
"status"of the result: an attribute
"errmsg"may also be available If
intern = FALSE, the return value is an error code (
0for success), given the invisible attribute (so needs to be printed explicitly). If the command could not be run for any reason, the value is
127. Otherwise if
wait = TRUEthe value is the exit status returned by the command, and if
wait = FALSEit is
0(the conventional success value). Some Windows commands return out-of-range status values (e.g.,
-1) and so only the bottom 16 bits of the value are used. If
intern = FALSE, wait = TRUE, show.output.on.console = TRUEthe
ignore.stdout = TRUEor
ignore.stderr = TRUE) output from a command that is a ‘console application’ should appear in the R console (
Rgui) or the window running R (
Rterm). Not all Windows executables properly respect redirection of output, or may only do so from a console application such as
Rtermand not from
Rgui: for example,
fc.exewas among these in the past, but we have had more success recently.
stderrwill be sent to the terminal unless
ignore.stderr = TRUE. They can be captured (in the most likely shells) by
system("some command 2>&1", intern = TRUE)For GUIs, what happens to output sent to
intern = FALSEis interface-specific, and it is unsafe to assume that such messages will appear on a GUI console (they do on the macOS GUI's console, but not on some others).
Rtermis being used, and whether a console command or GUI application is run by the command. By default nothing will be seen in either front-end until the command finishes and the output is displayed. For console commands
Rguiwill open a new ‘console’, so if
invisible = FALSE, a commands window will appear for the duration of the command. For
Rterma separate commands window will appear for console applications only if
wait = FALSEand
invisible = FALSE. GUI applications will not display in either front-end unless
invisibleis false. It is possible to interrupt a running command being waited for from the keyboard (using the Esc key in
Rguior Ctrl-C in
Rterm) or from the
Rguimenu: this should at least return control to the R console. R will attempt to shut down the process cleanly, but may need to force it to terminate, with the possibility of losing unsaved work, etc. Do not try to run console applications that require user input from
intern = TRUEor
show.output.on.console = TRUE. They will not work.
systembehaves. For the benefit of programmers, the more important ones are summarized in this section.
systemlaunches a shell which then runs
command. On Windows the command is run directly -- use
shellfor an interface which runs
commandvia a shell (by default the Windows shell
cmd.exe, which has many differences from a POSIX shell). This means that it cannot be assumed that redirection or piping will work in
system(redirection sometimes does, but we have seen cases where it stopped working after a Windows security patch), and
shell) must be used on Windows.
stderrwhen not captured depends on how R is running: Windows batch commands behave like a Unix-alike, but from the Windows GUI they are generally lost.
system(intern = TRUE)captures
stderrwhen run from the Windows GUI console unless
ignore.stderr = TRUE.
shQuoteis a portable interface.
invisibleonly do something on Windows (and are most relevant to
system2for a more portable and flexible interface which is recommended for new code.
commandis parsed as a command plus arguments separated by spaces. So if the path to the command (or a single argument such as a file path) contains spaces, it must be quoted e.g. by
shQuote. Only double quotes are allowed on Windows: see the examples. (Note: a Windows path name cannot contain a double quote, so we do not need to worry about escaping embedded quotes.)
commandmust be an executable (extensions
.com) or a batch file (extensions
.bat): these extensions are tried in turn if none is supplied.) This means that redirection, pipes, DOS internal commands, … cannot be used: see
shellif you want to pass a shell command-line. The search path for
commandmay be system-dependent: it will include the R
bindirectory, the working directory and the Windows system directories before
PATH. Unix-alikes pass the command line to a shell (normally
/bin/sh, and POSIX requires that shell), so
commandcan be anything the shell regards as executable, including shell scripts, and it can contain multiple commands separated by
;. On Windows,
systemdoes not use a shell and there is a separate function
shellwhich passes command lines to a shell. If
popenis used to invoke the command and the output collected, line by line, into an R
FALSEthen the C function
systemis used to invoke the command.
waitis implemented by appending
&to the command: this is in principle shell-dependent, but required by POSIX and so widely supported. The ordering of arguments after the first two has changed from time to time: it is recommended to name all arguments after the first. There are many pitfalls in using
systemto ascertain if a command can be run ---
Sys.whichis more suitable.
shell.execfor a less raw interface.
man shfor how this is implemented on the OS in use.
.Platformfor platform-specific variables.
pipeto set up a pipe connection.
# list all files in the current directory using the -F flag ## Not run: system("ls -F") # t1 is a character vector, each element giving a line of output from who # (if the platform has who) t1 <- try(system("who", intern = TRUE)) try(system("ls fizzlipuzzli", intern = TRUE, ignore.stderr = TRUE)) # zero-length result since file does not exist, and will give warning.
Run the code above in your browser using DataCamp Workspace