Using rw0642 under win95, on executing from a directory on the c: drive:
system("command.com /c dir", intern=T)
there is a whirring from drive a: (empty), then the message appears in a
dos box:
General failure reading device aLP!!?
Abort, Retry, Fail?
Repeating the command a few times finally results in success with no
whirring, after which there are no failures (even after restarting R)
until the computer is rebooted.
The computer is on a TCP/IP network with slow automounting, though the c:
drive is of course local. It is set to try booting first from drive a:.
Could this be a timeout problem which could be fixed either in R or with
some setting in win95?
Thanks for R
----------------------------------------------------------------------------
John Peters
CSIRO National Measurement Laboratory
PO Box 218 Phone: +61 2 9413 7503
Lindfield NSW 2070 Fax: +61 2 9413 7202
Australia Internet: John.Peters@tip.CSIRO.AU
----------------------------------------------------------------------------
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !) To:
r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
John.Peters@tip.csiro.au writes:> Using rw0642 under win95, on executing from a directory on the c: drive: > > system("command.com /c dir", intern=T) > > there is a whirring from drive a: (empty), then the message appears in a > dos box: > > General failure reading device aLP!!? > Abort, Retry, Fail?Not that I know anything about Windows, but is there a chance that the machine goes looking for command.com on the diskette? I.e. you want c:\\windows\\command.com instead. -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907 -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
Why was this a bug report? It does not seem to me to meet the requirements of a bug given in the R FAQ. On 22 Jul 1999, Peter Dalgaard BSA wrote:> John.Peters@tip.csiro.au writes: > > > Using rw0642 under win95, on executing from a directory on the c: drive: > > > > system("command.com /c dir", intern=T) > > > > there is a whirring from drive a: (empty), then the message appears in a > > dos box: > > > > General failure reading device aLP!!? > > Abort, Retry, Fail? > > Not that I know anything about Windows, but is there a chance that the > machine goes looking for command.com on the diskette? I.e. you want > c:\\windows\\command.com instead.Not on my machine: that command works for me. What do you (John) expect this command to do? In particular, what directory does you expect it to list? You have not told it, and Windows has quite complicated rules for finding the current working directory. My guess is that those rules are giving a: in your circumstances. Put a floppy in and find out. Tip: using shell() would be much simpler. Try ?shell (on Windows only). -- Brian D. Ripley, ripley@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272860 (secr) Oxford OX1 3TG, UK Fax: +44 1865 272595 -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
Prof Brian D Ripley writes:> Why was this a bug report? It does not seem to me to meet the requirements > of a bug given in the R FAQ. > > On 22 Jul 1999, Peter Dalgaard BSA wrote: > > > John.Peters@tip.csiro.au writes: > > > > > Using rw0642 under win95, on executing from a directory on the c: drive: > > > > > > system("command.com /c dir", intern=T) > > > > > > there is a whirring from drive a: (empty), then the message appears in a > > > dos box: > > > > > > General failure reading device aLP!!? > > > Abort, Retry, Fail? > > > > Not that I know anything about Windows, but is there a chance that the > > machine goes looking for command.com on the diskette? I.e. you want > > c:\\windows\\command.com instead. > > Not on my machine: that command works for me. > > What do you (John) expect this command to do? In particular, what directory > does you expect it to list? You have not told it, and Windows has quite > complicated rules for finding the current working directory. My guess > is that those rules are giving a: in your circumstances. Put a floppy > in and find out. > > Tip: using shell() would be much simpler. Try ?shell (on Windows only).Firstly a workaround (fix?): Disable McAfee VirusScan 4.0.2/4.0.4032. If this means it could be described as more an incompatibility than a bug I apologise. Secondly to respond to the comments and suggestions (McAfee enabled): What do I expect this command to do: To read the names of the files in the current directory for assignment to a vector. By current directory I mean the one named in the win95 shortcut "Start in:" box, which is also the one initially offered by the Rgui pull down "File - Change dir". It succeeds in this, but not on the first attempt. Put a floppy in drive a: Less whirring, but same result. Hitting "a" gives the behaviour I described. Hitting "f" succeeds after a few tries, but next time again needs a few tries before succeeding. So far it seems exactly four "f"s or three "a"s are required. Try shell(): Both the following cause the same behaviour as with "system()": shell("dir c:\\tmp\\9907","c:\\windows\\command.com",intern=T) shell("dir","command.com",intern=T) Many thanks ---------------------------------------------------------------------------- John Peters CSIRO National Measurement Laboratory PO Box 218 Phone: +61 2 9413 7503 Lindfield NSW 2070 Fax: +61 2 9413 7202 Australia Internet: John.Peters@tip.CSIRO.AU ---------------------------------------------------------------------------- -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
On Fri, 23 Jul 1999, John Peters wrote:> Firstly a workaround (fix?): > > Disable McAfee VirusScan 4.0.2/4.0.4032. If this means it could > be described as more an incompatibility than a bug I apologise.Yes, I would put that down to a system problem. The reason for being picky is that bug reports need to be written up, ... It looks to me as if McAfee has replaced the Windows `search for executables' routine and uses that to go for a virus search. Not much we can do about that.> Try shell(): > Both the following cause the same behaviour as with "system()": > shell("dir c:\\tmp\\9907","c:\\windows\\command.com",intern=T) > shell("dir","command.com",intern=T)It will do as it too has to search for an executable. -- Brian D. Ripley, ripley@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272860 (secr) Oxford OX1 3TG, UK Fax: +44 1865 272595 -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._