Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I have a problem with viewing chunks of a very large text file. This file, approximately 19 GB, is obviously too big to view by any traditional means.

I have tried head 1 and tail 1 (head -n 1 and tail -n 1) with both commands piped together in various ways (to get at a piece in the middle) with no luck. My Linux machine running Ubuntu 9.10 cannot process this file.

How do I handle this file? My ultimate goal is to hone in on lines 45000000 and 45000100.

share|improve this question
    
Thinking of writing a quick Python script to read the lines and print the ones I need to file, but I can imagine this taking a long time... –  nicorellius Feb 21 '12 at 0:04
    
Are all the lines the same length? –  Paul Feb 21 '12 at 0:10
    
@Paul - unfortunately, they are not the same length. –  nicorellius Feb 21 '12 at 0:15
    
You can try split to make the large file easier to work with. –  iglvzx Feb 21 '12 at 0:24
1  
Ok. Any processing of a file that large will take time, so the answers below will help that. If you want to extract just the part you are looking for and can estimate approximately where it is you can use dd to get the bit you are after. For example dd if=bigfile of=extractfile bs=1M skip=10240 count=5 will extract 5MB from the file starting from the 10GB point. –  Paul Feb 21 '12 at 1:38
show 1 more comment

2 Answers 2

up vote 6 down vote accepted

You should use sed.

sed -n -e 45000000,45000100p -e 45000101q bigfile > savedlines

This tells sed to print lines 45000000-45000100 inclusive, and to quit on line 45000101.

share|improve this answer
add comment

Create a MySQL database with a single table which has a single field. Then import your file into the database. This will make it very easy to look up a certain line.

I don't think anything else could be faster (if head and tail already fail). In the end, the application that wants to find line n has to seek through the whole file until is has found n newlines. Without some sort of lookup (line-index to byte offset into file) no better performance can be achieved.

Given how easy it is to create a MySQL database and import data into it, I feel like this is a viable approach.

Here is how to do it:

DROP DATABASE IF EXISTS helperDb;
CREATE DATABASE `helperDb`;
CREATE TABLE `helperDb`.`helperTable`( `lineIndex` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, `lineContent` MEDIUMTEXT , PRIMARY KEY (`lineIndex`) );
LOAD DATA INFILE '/tmp/my_large_file' INTO TABLE helperDb.helperTable (lineContent);
SELECT lineContent FROM helperTable WHERE ( lineIndex > 45000000 AND lineIndex < 45000100 );

/tmp/my_large_file would be the file you want to read.

The correct syntax to import a file with tab-delimited values on each line, is:

LOAD DATA INFILE '/tmp/my_large_file' INTO TABLE helperDb.helperTable FIELDS TERMINATED BY '\n' (lineContent);

Another major advantage of this is, if you decide later on to extract another set of lines, you don't have to wait hours for the processing again (unless you delete the database of course).

share|improve this answer
    
So this is a good solution, indeed. I got it to work with the sed command below, and identified my lines. But now I have a follow up question that the database method may be better suited for. I now need to delete a couple hundred lines from the file. –  nicorellius Feb 21 '12 at 18:18
    
I'm sure sed could do that as well. Of course, if you had the data in the database it would be trivial to export a new file with just the lines you want. –  Oliver Salzburg Feb 21 '12 at 18:22
    
Thanks again. I took the sed answer (because it gave me more immediate pleasure ;--) but gave you an up-vote because I will use your method in the future. I appreciate it. –  nicorellius Feb 21 '12 at 18:37
1  
You could try adding a FIELDS TERMINATED BY '\n' to the LOAD DATA line. –  Oliver Salzburg Feb 21 '12 at 22:35
1  
I'm sorry, there was a mistake in my code. I also added the correct syntax for your case (tested this time). –  Oliver Salzburg Feb 22 '12 at 0:20
show 3 more comments

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.