I just wanted to add that it is not only caused by the FIND.EXE, but I
also noticed the same problem with DOSKEY.EXE. It too causes the same
fault, but the redirection (
To:
Duncan Murdoch
Cc:
Uwe Ligges , John Schexnayder/San
Jose/i...@ibmus, r-h...@stat.math.ethz.ch
Date:
01/10/2010 10:42 AM
Subject:
Re: [R] Calling FING.EXE under RGui.EXE for windows.
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
wrote:
> 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 /?
> or
>
> shell("c:/WINDOWS/system32/find \"Hello\" c:/temp/foo.txt
> 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:
>>
>> 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
>> wrote:
>>>
>>> On 09/01/2010 6:31 PM, Gabor Grothendieck wrote:
>>>>
>>>> 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)
>>>
>>> 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
>>>
>>>> On Sat, Jan 9, 2010 at 5:24 PM, Duncan Murdoch
>>>> wrote:
>>>>>
>>>>> On 07/01/2010 1:25 PM, Uwe Ligges wrote:
>>>>>>
>>>>>> Argh. I see it as well. Will dig a lit tomorrow.
>>>>>
>>>>> 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
>>>>>
>>>>>> Uwe
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 07.01.2010 12:25, Gabor Grothendieck wrote:
>>>>>>>
>>>>>>> I get a problem with shell too:
>>>>>>>
>>>>>>> Under Rgui:
>>>>>>>
&
