I'm not holding it against him... I'm holding it against you ;-) 

Bill's solution is no less "computationally complex" than any of the correct 
solutions, which all involved reading the file, and skipping the first 300 
lines. The original poster didn't say he wanted to feed the result to STDIN of 
another process, but rather:
> Grant Kelly wrote:
> > I have a text file, it's about 2.3 GB. I need to delete the first 300
> > lines, and I don't want to have to load the entire thing into an
> > editor.

Given this information, the proposed solutions where all reasonable. Once we 
had more information, more elegant solutions where available.

"Computational Complexity" has little to do with what the command line "looks 
like", but rather what goes on inside the program. 

Sorry to be so pedantic about this... 


On Thu, 29 Jun 2006 23:21:36 -0700 (PDT)
Sebastian Smith <[EMAIL PROTECTED]> wrote:

> True, but the proposed solution is less computationally complex... 
> assuming it actually solves the problem at hand.  Bill mentioned that 
> his command format was probably incorrect, so you should not hold that 
> against him.  It's the idea that counts.
> 
> 
> On Thu, 29 Jun 2006, James Washer wrote:
> 
> > Reasonable... not quite.. that command will give you ONLY THE LAST 300 
> > lines... There have been quite a number of reasonable solutions offered 
> > however.
> >
> > Further "<" syntax works with files, not command standard output
> >
> > On Thu, 29 Jun 2006 22:36:05 -0700 (PDT)
> > Sebastian Smith <[EMAIL PROTECTED]> wrote:
> >
> >> Wow!  It only took us two days to find a resonable solution ;)
> >>
> >>
> >> On Thu, 29 Jun 2006, Bill Cunningham wrote:
> >>
> >>> I know the original question was to truncate the first 300 lines of the 
> >>> file but why do that when you could just solve the problem without 
> >>> modifying the original file at all. If the purpose is to not send the 
> >>> first 300 bytes to a command then simply use the tail command:
> >>>
> >>> tail -300 original_file
> >>>
> >>> So if you wanted to feed the original file to mysql you could use:
> >>>
> >>> mysql < tail -300 original_file
> >>>
> >>> ( I'm a little rusty so man tail to find the exact command.) I'm of the 
> >>> belief of keep it simple. Why modify the file at all?
> >>>
> >>> Bill Cunningham
> >>>
> >>> ----- Original Message ----
> >>> From: P_Thorne <[EMAIL PROTECTED]>
> >>> To: [email protected]
> >>> Sent: Thursday, June 29, 2006 7:08:39 PM
> >>> Subject: [RLUG] Re: quick question
> >>>
> >>> This idea wouldn't satisfy the original premise of the thread that the
> >>> file couldn't exist twice:
> >>> Has anyone thought of using the shell command "split"?   I have used
> >>> split or csplit to vi edit small portions of very large ascii files,
> >>> recombining the big file using "cat".   It would probably not have been
> >>> any faster than using "sed" as the original author did, but you might be
> >>> able to do more complex editing.
> >>>
> >>>
> >>> _______________________________________________
> >>> RLUG mailing list
> >>> [email protected]
> >>> http://lists.rlug.org/mailman/listinfo/rlug
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> RLUG mailing list
> >>> [email protected]
> >>> http://lists.rlug.org/mailman/listinfo/rlug
> >>>
> >>
> >> _______________________________________________
> >> RLUG mailing list
> >> [email protected]
> >> http://lists.rlug.org/mailman/listinfo/rlug
> >>
> >
> > _______________________________________________
> > RLUG mailing list
> > [email protected]
> > http://lists.rlug.org/mailman/listinfo/rlug
> >
> 
> _______________________________________________
> RLUG mailing list
> [email protected]
> http://lists.rlug.org/mailman/listinfo/rlug
> 

_______________________________________________
RLUG mailing list
[email protected]
http://lists.rlug.org/mailman/listinfo/rlug

Reply via email to