Skip to content

Calling FING.EXE under RGui.EXE for windows.

22 messages · John Schexnayder, Uwe Ligges, Henrik Bengtsson +2 more

Gabor Grothendieck
# 
If you have C:\Rtools\bin on your PATH note that it contains a
UNIX-like find utility that conflicts with the find utility in
Windows.  If that is the problem then remove that from your PATH and
then run the batch file.

The batchfiles distribution at http://batchfiles.googlecode.com  has
utilities (Rgui.bat, R.bat, Rtools.bat, etc.) that will automatically
add C:\Rtools\bin to your path temporarily or only while R is running
so that you can leave it off your PATH.
On Wed, Jan 6, 2010 at 6:51 PM, John Schexnayder <jschex at us.ibm.com> wrote:
Uwe Ligges
#
On 07.01.2010 02:04, Gabor Grothendieck wrote:
I guess it's the use of system() rather than shell() that causes the 
problem. Under Windows, you have to use shell in order to start a 
command interpreter.

Uwe Ligges
Gabor Grothendieck
# 
I get a problem with shell too:

Under Rgui:
[1] "R version 2.10.1 Patched (2010-01-01 r50884)"
character(0)
character(0)
Warning message:
In shell("C:\\windows\\system32\\find /?") :
 'C:\windows\system32\find /?' execution failed with error code 1

They all work, i.e. they give the required help message, under Rterm
and when I issue this from the Windows console it works:
C:\windows\system32\find /?


2010/1/7 Uwe Ligges <ligges at statistik.tu-dortmund.de>:
Uwe Ligges
# 
Argh. I see it as well. Will dig a lit tomorrow.

Uwe
On 07.01.2010 12:25, Gabor Grothendieck wrote:
Henrik Bengtsson
# 
No paths for shell() - instead throw it commands as if you were at the
Windows command prompt, i.e.

res <- shell("find", intern=TRUE);
str(res);
 chr [1:3454] "." "./.Rhistory" "./aroma.affymetrix" ...

/H

2010/1/7 Uwe Ligges <ligges at statistik.tu-dortmund.de>:
Henrik Bengtsson
# 
My bad, I jumped in to late in the thread and missed the fact that it
does not work with Rgui.exe (and that it works with Rterm.exe).
Problem replicated/remains. /H
On Thu, Jan 7, 2010 at 11:10 AM, Henrik Bengtsson <hb at stat.berkeley.edu> wrote:
2 days later
Duncan Murdoch
#
On 07/01/2010 1:25 PM, Uwe Ligges wrote:
I don't know exactly what's going on, but it looks as though it is 
something specific to the find.exe utility, e.g. maybe it is assuming 
that it's being run inside a console and reading CONIN$ or writing to 
CONOUT$ without checking whether they can be opened.  When you run it 
from Rterm, Rterm is in a console, which appears to be good enough.

So it may be anyone who wants to use it will have to contact Microsoft 
to find out how...

Duncan Murdoch
Gabor Grothendieck
# 
That doesn't explain why this returns character(o) even though we have
launched a console for it:

system("cmd /c C:\\windows\\system32\\find /?", intern = TRUE)
On Sat, Jan 9, 2010 at 5:24 PM, Duncan Murdoch <murdoch at stats.uwo.ca> wrote:
Duncan Murdoch
#
On 09/01/2010 6:31 PM, Gabor Grothendieck wrote:
I don't see any console launched.  R redirects stdin and stdout (and 
stderr, I think), and it appears that Windows doesn't open a console.  I 
do see a console flash by if I do

system('cmd /c c:/WINDOWS/system32/find.exe /?', wait=FALSE, 
invisible=FALSE)

but of course then we don't capture the output, so it's not very useful. 
  Looking at the source, the only case where we ask to create a console 
is the combination "wait=FALSE, invisible=FALSE", but there might be 
combinations of other options that make this a default.  The MS 
documentation says that a console will be created automatically for any 
console application, but that doesn't appear to be happening.

So I guess you could get find.exe to work by calling it from a batch 
file with a "pause" at the end and using the wait=FALSE,invisible=FALSE 
options.

The above observations are in Win XP SP3, not anything newer.

Duncan Murdoch
Gabor Grothendieck
# 
I noticed this does work, i.e. it displays the requested help info, in
Rgui on my Vista system:

library(tcltk)
.Tcl("exec find /?")
On Sat, Jan 9, 2010 at 7:27 PM, Duncan Murdoch <murdoch at stats.uwo.ca> wrote:
Duncan Murdoch
#
Gabor Grothendieck wrote:
Yes, here too.  It stores the output in a tclObj, so it's doing what we 
want to do.  Anyone familiar with the Tcl source, and can spot the 
difference between their exec and our system()?

Duncan Murdoch
Henrik Bengtsson
# 
Article ID: 106203 - Last Review: November 1, 2006 - Revision: 3.1
FIND.EXE Does Not Return the Proper Errorlevel in Windows NT
http://support.microsoft.com/kb/106203

/Henrik
On Sun, Jan 10, 2010 at 5:39 AM, Duncan Murdoch <murdoch at stats.uwo.ca> wrote:
Henrik Bengtsson
# 
Forgot to say that when you use that findit.bat script, you get:

Rgui.exe:
Errorlevel is 1,  not found
Errorlevel is 1,  not found

Rterm.exe:
c:\config.sys
Errorlevel is 0,  found
c:\config.sys
Errorlevel is 0,  found

Windows Vista Business SP2
R version 2.10.1 Patched (2010-01-01 r50884)
i386-pc-mingw32

locale:
[1] LC_COLLATE=English_United States.1252
[2] LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United States.1252

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base

loaded via a namespace (and not attached):
[1] tools_2.10.1

/H


2010/1/10 hb <hb at stat.berkeley.edu>:
Henrik Bengtsson
# 
Hello world
[1] "Hello world"
Hello world
[1] "Hello world"

A person at http://www.experts-exchange.com/Programming/Misc/Q_20857955.html
give the hypotheses that the 'Errorlevel' returned is not from whether
'find.exe' was executed or not, but whether find finds the string or
not.  This is consistent with:
Hello world
[1] 0
Warning message:
In shell("find \"Hellor\" < foo.txt") :
  'find "Hellor" < foo.txt' execution failed with error code 1
[1] 1


I still don't understand their argument why you have to redirect/pipe
in the foo.txt file for it to work;
Warning message:
In shell("find \"Hello\" foo.txt") :
  'find "Hello" foo.txt' execution failed with error code 1
character(0)

/Henrik


2010/1/10 hb <hb at stat.berkeley.edu>:
Duncan Murdoch
# 
I'm quitting on this one.  For the record, I took a look at a fairly old 
version of the Tcl code (from 8.4.13) that I had around from an old 
attempt to get it to work properly with MDI windows.  There are a number 
of differences between their exec code and our system() code, but I 
couldn't find the right combination to get system() to be able to run 
find.  It always crashes with a seg fault in ulib.dll when run with 
input coming from the pipe we send it.

If you use input redirection on the command line, it's fine, for example

system("cmd /c c:/WINDOWS/system32/find /? <nul")

or

shell("c:/WINDOWS/system32/find \"Hello\" c:/temp/foo.txt <nul")

So perhaps we're not setting up the pipe correctly, but it works with 
most other programs, so I'm going to assume find is using it 
incorrectly, unless someone points out what we're doing wrong.

Duncan Murdoch
On 10/01/2010 8:18 AM, Gabor Grothendieck wrote:
Gabor Grothendieck
# 
Perhaps you can add it to the bug list before you leave it including
what you tried in case its a symptom of some larger underlying
problem.
On Sun, Jan 10, 2010 at 1:24 PM, Duncan Murdoch <murdoch at stats.uwo.ca> wrote:
Duncan Murdoch
#
On 10/01/2010 1:42 PM, Gabor Grothendieck wrote:
This list is archived, so there's a record.  But I think this is a find 
bug, not an R bug, so it doesn't make sense to add it to the R bug list.

Duncan Murdoch
Gabor Grothendieck
# 
That may be but given that tcl does not have the same problem it might
still be something that would be desirable to address and it is
possible that it is a symptom of a larger problem in R.  It will more
likely be lost if its buried in this discussion.
On Sun, Jan 10, 2010 at 1:51 PM, Duncan Murdoch <murdoch at stats.uwo.ca> wrote:
1 day later
Duncan Murdoch
#
On 11/01/2010 2:56 PM, John Schexnayder wrote:
I don't find it very surprising.  cmd.exe doesn't have the bug, so "copy 
/?" works fine.  find.exe and apparently xcopy.exe do, so they fail.

It's not a bug in doskey that it doesn't work; it's supposed to talk to 
the console, so if there is no console, it won't work.  But find and 
xcopy have no business talking to the console.  They should simply work 
with stdin/stdout.

Duncan Murdoch
10 days later
Duncan Murdoch
#
On 10/01/2010 1:51 PM, Duncan Murdoch wrote:
Turns out it was probably both.  R definitely had a bug, and find 
reacted to it in a fairly strange way.

I've just committed fairly extensive changes to the low-level system() 
and related code in R.  They fix some problems reported yesterday in 
Windows 7, as well as the find.exe problems reported in this thread.  
They may introduce some new ones; please test and let me know if you see 
anything.

I committed the changes to both R-devel and R-patched; builds after 
r51015 should contain them.

Duncan Murdoch