Skip to content

use of "input" in system()

7 messages · Duncan Murdoch, Mike Miller, Wacek Kusnierczyk

#
First, it looks like there is bug in the documentation...

According to the documentation for system():

http://stat.ethz.ch/R-manual/R-patched/library/base/html/system.html

   input  if a character vector is supplied, this is copied one string per
          line to a temporary file, and the standard input of command is
          redirected to the file

This seems to mean that the standard input of command is redirected *from* 
the file.  From the file, to the command.  Example:
42

I guess the documentation needs to be clarified because I couldn't 
understand what it meant.

Second, I'm trying to use a system call to write files with names based on 
an integer value in an R variable (in this case the variable is called 
"i").  As above, I can do this (on a GNU/Linux system):
0005

I am running bash, but system calls go to sh.  I want to be able to put 
that input string ("0005") into a variable and do something like this:

system( "i=`cat /dev/stdin` ; run_script > file${i}.out" , input=sprintf("%04d", i) )

I think my problem is more with sh than with R, but someone here must have 
tried this, so I'm hoping I can get an answer here.  Thanks in advance.

Best,
Mike
#
On 4/24/2009 10:29 AM, Mike Miller wrote:
The redirection is done *to* the file handle.  The fact that input is 
read from that handle is a different issue.

Duncan Murdoch
#
On Fri, 24 Apr 2009, Mike Miller wrote:

            
In sh, both of these commands execute ls:

echo ls | `cat /dev/stdin`
echo ls | `cat -`

In R, both of these simply hang until I hit ctrl-c...
...but the stdin is getting to the command because both of these return 
"ls" to stdout:
So what am I missing?  I don't understand why the backtick method isn't 
working.  Is there another way to do this?

Mike
#
On Fri, 24 Apr 2009, Mike Miller wrote:

            
I still can't figure that out, but it is OK because I found a better way. 
For some reason I was thinking of the system function like this...

system( "command" )

...when I could have been thinking of it like this:

foo <- "command"

system( foo )

Maybe obvious in retrospect, but that makes it much easier to take values 
from R and insert them into system commands.  Here is a mini example:
[1] "touch file0005.out"

Thus I have placed two system commands into variables foo and bar.  The 
system commands can be pasted together using " ; " as a separator...
[1] "touch file0005.out ; ls"


...then executed like so:
Mike

Michael B. Miller, Ph.D.
Minnesota Center for Twin and Family Research
Department of Psychology
University of Minnesota
5 days later
#
On Fri, 24 Apr 2009, Duncan Murdoch wrote:

            
Thanks very much for the reply.  After seeing your response, I'm sure the 
document isn't wrong (not a bug) but it is a very terse explanation that I 
think many people will find hard to follow, as I did.

First, a temporary file is created.  Where is it?  What is it called?  If 
the name/location don't matter, does it even matter that a temporary file 
is created?  Is this just info about the internal workings of R that the 
user doesn't need to know?

Then "the standard input of command is redirected to the file".  I think I 
get this now.  I think it means that this is being done behind the scenes:

command < file

Would it help users to tell them that, if that is correct?  It would have 
helped me.  I think this is basically what it is doing:

# For input to the system command we'll need a command and a vector:
command <- "any command string"
v <- c("some", "vector")

# make a temp file:
filename <- tempfile( tmpdir=tempdir() )
write.table(v, file=filename, sep="\n", row.names=FALSE, col.names=FALSE, quote=FALSE)

# Then I think these two system commands do the same thing:

system( paste(command, "<", filename, sep=" ") )

system( command, input=v )

It would be nice if there were more documentation so that I could 
understand this better.  I wasn't understanding why system() hangs 
sometimes as in the simple examples below, but I think I get it now:  The 
stdout goes only to the last command in a string of semi-colon-separated 
commands.  If that's right, it makes sense.

Mike


This works:
foo


This hangs until I hit ctrl-c:
This works:
bar
foo


This hangs until I hit ctrl-c:
Best,
Mike
#
Mike Miller wrote:
it doesn't seem to be the usual way of explaining the matters.  the bash
reference manual [1, sec. 3.6.1] (see also man bash) says:

"
Redirection of input causes the file whose name results from the
expansion of word to be opened for reading on file descriptor |n|, or
the standard input (file descriptor 0) if |n| is not specified.

The general format for redirecting input is:

     [n]<word

"

it definitely not saying 'redirection to'.  even more contrary to what
duncan says is man page of the sh shell (man sh):

"
[n]< file   Redirect standard input (or n) from file.
"

note the *from*.

in peters' expert shell scripting [1, ch. 9, p. 60] it is stated:

"
expression < file: Redirect the contents of file into the expression.
"

while r's "standard input of command is redirected to the file" can
certainly be read correctly once one knows what it really means, it is
an unfortunate and misleading expression, and it might be a good idea to
fix it. 

yet another example of how creative documentation is not necessarily
good documentation.

vQ
#
Wacek Kusnierczyk wrote and forgot to add references:
[1] http://www.gnu.org/software/bash/manual/bashref.html
[2] Ron Peters, Expert Shell Scripting, Apress 2009

vQ