similar to: getting corrupted data when using readBin() after seek() on a gzfile connection

I have been trying to use the gunzip function in the R.utils package. It opens a connection to a gzfile, uses readBin to read from that connection, and then uses writeBin to write out the raw data to a new file. This works as expected under linux/mac, but under Windows, I get: Error in readBin(inn, what= raw(0), size = 1, n=BFR.SIZE) : negative length vectors are not allowed A simple

Hi, A piece of my code that uses readBin() to read a certain file type is behaving strangely with R 2.7.0. This seems to be because of a failure to match() strings after using rawToChar() when the original was terminated with a "\0" character. Direct equality testing with == still works as expected. I can reproduce this as follows: > x <- "foo" > y <-

Hi all, in the last time I've intensively used Rstreams to read and write from binary files. Now I'm wondering if it is possible to use Rsteams functions with gzipped files. But I haven't found the trick: > p1c.gzip <- gzfile("daten/p1c_all.mea.gz", open="rb") > readBin(p1c.gzip, integer(), n=64,size=2) [1] 84 1 400 1 749 0 0 0

If I open a tgz archive with gzfile and then parse it using readLines I miss the initial line of each member of the archive - and also the name of the file although the archive otherwise complete (but useless!). Is there any way within R to extract both the list of files in a tgz archive and to extract any one of these files? Clearly I can use zcat and tar on Linux, but I need this to work

Working on Windows I have had to deal with CSV files that, unfortunately, contain embedded Control-Zs, i.e. ASCII character 26 in decimal, and the readLines() function in R on Windows (2.15.2 and 3.0.0) appears to truncate at the control-Z. There is no problem at all on Ubuntu Linux with R 3.0.0. Am I mistaken or is this genuine? # Create a small file with embedded Control-Z h3 <-

I often want to use "pipe" with "readBin" to read (binary) data from the standard output of a Perl or C program. For that I need "pipe" to work with the "open='rb'" option. It never worked for me, and after a look at the connections.c file, I see that in "pipe_open" the mode gets passed directly to "popen" (I'm using Linux on

Hi all, I used `gzfile` and `gzcon` to read a compressed file but I found that `gzcon` gave me a different result than `gzfile`. It seems like the `gzcon` does not handle the data correctly. I have posted an example below. In the example, a portion of a compressed file is downloaded from Google Cloud as a raw vector, and the data is saved into a temp file. If I use ` gzfile` to read the file, it

Full_Name: Vadim Ogranovich Version: Version 1.6.0 (2002-10-01) OS: Red Hat 7.1 Submission from: (NULL) (209.99.241.1) The following sequence of commands crashes my R session. The first weirdness happens after the second command that appears not to change the "foo.gz" file, no error generated. > con <- gzfile("foo.gz", open="w"); cat("goo\n",

I found that seek(..., origin = 'current', ...) and readBin(..., what = 'integer', ...) or 'int' do not work correctly. Did anyone have the same experience?

Hello! I have problems with using of "readBin" to read files, which was written in C with "fwrite". In the C-File there is the following Code: fwrite(MyitINI,sizeof(itINItype),1,outfile); where MyitINI is a structure of the following form typedef struct{ int KernelFileSave; /* Determined, if Systemmatrix saved or not.*/ char KernelFileName[200]; /* A-Matrix name

Dear All, I'd like to be able to have R store (in a list component) a compressed data set, and then write it out uncompressed. gzcon and gzfile work in exactly the opposite direction. What would be a good way to handle this? Details: ---------- We have a package that uses C; part of the C output is a large sparse matrix. This is never manipulated directly by R, but always by the C code.

R-devel: I am encountering a consistency issue using socketConnection and readBin with *non-blocking* connections on Unix and Windows XP (no Vista to test). I am a bit confused by the behavior of *non-blocking* connections under Windows specifically. When calling readBin on a non-blocking connection when there is no data to read on the socket, the connection under Unix will return a vector of

Dear all, I'm trying to write an efficient binary file reader for a file type that is made up of several fields of variable length, and so requires many small reads. Doing this on the file directly using a sequence of readBin() calls is a bit too slow for my needs, so I tried buffering the file into a raw vector and reading from that ("loc" is the equivalent of the file pointer):

Dear all, I'm trying to write an efficient binary file reader for a file type that is made up of several fields of variable length, and so requires many small reads. Doing this on the file directly using a sequence of readBin() calls is a bit too slow for my needs, so I tried buffering the file into a raw vector and reading from that ("loc" is the equivalent of the file pointer):

Hi, I am making multiple calls to gzfile() via read.table(), e.g. > x <- read.table( gzfile( "xxx.gz" ) ) After i do this many times (I haven't counted, but probably between 50 and 100 times) I get the error message: Error in open.connection(file, "r") : unable to open connection In addition: Warning message: cannot open compressed file 'xxx.gz' however, I

I would like to use readBin to read a binary data file. Most of the data is 4-byte floating point but, for some reason, only double precision appears to be offered. I tried fVariable=readBin(iFile,what=single()); and got 35.87879 which looks believable except that the correct value is 3.030303. I then tried fVariable=readBin(iFile,what=single(),4); and got [1] 3.831111e+10 6.657199e+10

I think it would be helpful if readBin checked that its endian argument is a legal value. Why? I was reviewing some of our code and noticed that the author had readBin(..., endian="network") and never having heard of "network", I looked at the man page for readBin, and it hadn't heard of "network" either. Not good. I then looked at the R code for readBin, which

Hi, The man page for readBin has a small typo: --- a/src/library/base/man/readBin.Rd +++ b/src/library/base/man/readBin.Rd @@ -58,7 +58,7 @@ writeBin(object, con, size = NA, endian \code{readBin} and \code{writeBin} read and write C-style zero-terminated character strings. Input strings are limited to 10000 - characters. \code{\link{readChar}} and \code{\code{writeChar}} +

When I read a .gz file with readLines() in 3.4.3, it returns text (and a warning). In 3.5.0, it gives a warning, but no text. Is this expected behavior or a bug? 3.4.3: > source_file = "1k_annotation.gz" > readfile_con <- gzfile(source_file, "r") > readLines(readfile_con, n = 5) [1] "#chr\tpos\tref\talt\t <truncated output here> Warning message: In

Hi folks: This may be a stupid question, but I cannot seem to find a way to tell readBin that I want to read 2-byte integers from the connection. The input file is 150,720 bytes long containing 75,360 short (2-byte) integers. But specifying "integer" or "int" for what in readBin only returns me a vector of length 37680, leading me to believe that sizeof(integer) or