R help - Apr 2010 - incomplete final line found by readTableHeader

Hi

I am trying this
> x <- read.table("/home/kenji/1245/GDS1_2grps_.cls", header =
F, skip = 2)
> x <- read.table("/home/kenji/1246/MYCset.cls", header = F,
skip = 2)
Warning message:
In read.table("/home/kenji/1246/MYCset.cls", header = F, skip = 2) :
  incomplete final line found by readTableHeader on
'/home/kenji/1246/MYCset.cls'

Here are the hex's

kenji at Yule:~$ hd 1245/GDS1_2grps_.cls
00000000  31 32 20 32 20 31 0a 23  20 43 44 31 39 2b 20 43  |12 2 1.# CD19+ C|
00000010  44 34 30 4c 0a 30 20 30  20 30 20 30 20 30 20 30  |D40L.0 0 0 0 0 0|
00000020  20 31 20 31 20 31 20 31  20 31 20 31 0a           | 1 1 1 1 1 1.|
0000002d
kenji at Yule:~$ hd 1246/
job938_MYC_RMA.gct  MYCset.cls          .MYCset.cls.swp
kenji at Yule:~$ hd 1246/MYCset.cls
00000000  31 32 20 32 20 31 0a 23  20 4d 59 43 20 4e 6f 74  |12 2 1.# MYC Not|
00000010  0a 30 20 30 20 30 20 30  20 30 20 30 20 31 20 31  |.0 0 0 0 0 0 1 1|
00000020  20 31 20 31 20 31 20 31                           | 1 1 1 1|
00000028

So it seems the problem is the linefeed (0a) absent in the second
file, probably generated by some evil excel or something like this.

My question is: is there any simple way to make read.table robust to
deal with this problem? I would like to avoid solutions such as
re-implement using scan or asking the user to deal with this for me,
changing himself the file.

Thanks in advance

Leonardo K. Shikida
Vetta Labs
+55(31)2551-6936 ext 203
http://www.vettalabs.com

On Apr 8, 2010, at 2:14 PM, Leonardo K. Shikida wrote:
> Hi
>
> I am trying this
>
>> x <- read.table("/home/kenji/1245/GDS1_2grps_.cls", header
= F,
>> skip = 2)
>> x <- read.table("/home/kenji/1246/MYCset.cls", header = F,
skip = 2)
> Warning message:
> In read.table("/home/kenji/1246/MYCset.cls", header = F, skip =
2) :
>  incomplete final line found by readTableHeader on
> '/home/kenji/1246/MYCset.cls'
>
> Here are the hex's
>
> kenji at Yule:~$ hd 1245/GDS1_2grps_.cls
> 00000000  31 32 20 32 20 31 0a 23  20 43 44 31 39 2b 20 43  |12 2  
> 1.# CD19+ C|
> 00000010  44 34 30 4c 0a 30 20 30  20 30 20 30 20 30 20 30  |D40L.0  
> 0 0 0 0 0|
> 00000020  20 31 20 31 20 31 20 31  20 31 20 31 0a           | 1 1 1  
> 1 1 1.|
> 0000002d
> kenji at Yule:~$ hd 1246/
> job938_MYC_RMA.gct  MYCset.cls          .MYCset.cls.swp
> kenji at Yule:~$ hd 1246/MYCset.cls
> 00000000  31 32 20 32 20 31 0a 23  20 4d 59 43 20 4e 6f 74  |12 2  
> 1.# MYC Not|
> 00000010  0a 30 20 30 20 30 20 30  20 30 20 30 20 31 20 31  |.0 0 0  
> 0 0 0 1 1|
> 00000020  20 31 20 31 20 31 20 31                           | 1 1 1 1|
> 00000028
>
> So it seems the problem is the linefeed (0a) absent in the second
> file, probably generated by some evil excel or something like this.
>
> My question is: is there any simple way to make read.table robust to
> deal with this problem? I would like to avoid solutions such as
> re-implement using scan or asking the user to deal with this for me,
> changing himself the file.
Did the line get read?

(I have failed in my efforts on a Mac to create a file with a text  
editor that throws that warning.) In a sense it appears to already be  
"robust" , since it only generated a warning, rather than an error. If
you want to programmatically turn off warnings, then:

?warnings
?options   # with a bunch of settings for warn

Perhaps inside your function you could call set warn = -1 the restore  
to =0 before exit.

options(warn=-1)
read.table( ...  )
options(warn=0)
>
> Thanks in advance
>
> Leonardo K. Shikida
> Vetta Labs
> +55(31)2551-6936 ext 203
> http://www.vettalabs.com
>
> ______________________________________________
> R-help at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide
http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.
David Winsemius, MD
West Hartford, CT