Trim last N lines from a file

[nikbackm]

I have a text file type where I have a need to discard the first N1 lines and the last N2 lines but keep everything in the middle. The length of the middle will usually vary from file to file.

The first N1 lines can be removed by using TAIL to skip them and then use a large N value to keep the rest.

I haven't found an easy way to remove the last N2 lines though. It seems to me that a combination of HEAD and TAIL should allow that to be done.

At least that is the case for the GNU versions.
http://stackoverflow.com/questions/...-from-the-tail-of-a-file-without-the-use-of-h

Might there be another way to achieve the same in TCC?

 

[Steve Fabian]

nikbackm wrote:
| I have a text file type where I have a need to discard the first N1
| lines and the last N2 lines but keep everything in the middle. The
| length of the middle will usually vary from file to file.
|
| The first N1 lines can be removed by using TAIL to skip them and
| then use a large N value to keep the rest.
|
| I haven't found an easy way to remove the last N2 lines though. It
| seems to me that a combination of HEAD and TAIL should allow that to
| be done.
|
| Might there be another way to achieve the same in TCC?

Certainly there is. Use the @LINES[] function to determine the file size,
and a little arithmetic to determine the number of lines to retain K. Now
the command
TAIL /n+N1 /nK file
will do exactly what you need. Just remember that the value of @LINES is an
offset, not line count; an empty file returns -1, a 1-line file returns 0.
The result will be something like this (NOT TESTED):

TAIL /n+N1 /n%@eval[ %@lines[file] - N1 - N2 + 1 ]
--
HTH, Steve

 

[vefatica]

On Wed, 07 Oct 2009 09:01:50 -0500, Steve Fábián <> wrote:

|Certainly there is. Use the @LINES[] function to determine the file size,
|and a little arithmetic to determine the number of lines to retain K. Now
|the command

I'm a little surprised that's necessary (as it seems to be). I suppose TAIL
knows how many lines are in the file (and has used up some time figuring it
out). The user shouldn't have to do it again. If HEAD has an option to skip
the first few lines of a file, TAIL should have one to skip the last few.
--
- Vince

 

[Steve Fabian]

vefatica wrote:
| I'm a little surprised that's necessary (as it seems to be). I
| suppose TAIL knows how many lines are in the file (and has used up
| some time figuring it out). The user shouldn't have to do it again.
| If HEAD has an option to skip the first few lines of a file, TAIL
| should have one to skip the last few. --

I agree. I suggest that the HEAD, TAIL, and TYPE commands could be collapsed
into a single enhanced TYPE command, which could have /B(egin), /E(nd), and
/Nn options. /B and /E would specify the beginning and ending line number to
be displayed, and /N the number of lines to be displayed, except when /X is
also used, they mean be bytes. Both /B and /E would work in the fashion used
by functions parsing lines, i.e., positive numbers start from the beginning
of the file, negative numbers count backwards from the end of file. In case
of overspecification (all three of the options specified) the command would
display only lines that match all restrictions. The parser could easily
convert - invisibly to the user - HEAD and TAIL commands, with their current
syntax, to the new TYPE command.

Another suggestion: the above partial file selection mechanism for the FFIND
command.
--
Steve

 

[samintz]

Wouldn't it be easier to just modify the HEAD command to accept negative
numbers so it works more like the GNU command?

-Scott

Steve F$BaC(Bi$BaO(B <> wrote on 10/07/2009 11:35:07 AM:

> vefatica wrote:
> | I'm a little surprised that's necessary (as it seems to be). I
> | suppose TAIL knows how many lines are in the file (and has used up
> | some time figuring it out). The user shouldn't have to do it again.
> | If HEAD has an option to skip the first few lines of a file, TAIL
> | should have one to skip the last few. --
>
> I agree. I suggest that the HEAD, TAIL, and TYPE commands could be

collapsed

> into a single enhanced TYPE command, which could have /B(egin), /E(nd),

and

> /Nn options. /B and /E would specify the beginning and ending line

number to

> be displayed, and /N the number of lines to be displayed, except when /X

is

> also used, they mean be bytes. Both /B and /E would work in the fashion

used

> by functions parsing lines, i.e., positive numbers start from the

beginning

> of the file, negative numbers count backwards from the end of file. In

case

> of overspecification (all three of the options specified) the command

would

> display only lines that match all restrictions. The parser could easily
> convert - invisibly to the user - HEAD and TAIL commands, with their

current

> syntax, to the new TYPE command.
>
> Another suggestion: the above partial file selection mechanism for the

FFIND

> command.
> --
> Steve
>
>
>
>

 

[rconn]

> I'm a little surprised that's necessary (as it seems to be). I suppose
> TAIL knows how many lines are in the file (and has used up some time
> figuring it out). The user shouldn't have to do it again.

TAIL has no idea how many lines are in the file. (It starts from the end
and counts backwards.)

Nor would you want it to -- it would be *seriously* slow on large files.

Rex Conn
JP Software

 

[nikbackm]

Certainly there is. Use the @LINES[] function to determine the file size,
and a little arithmetic to determine the number of lines to retain K. Now
the command
TAIL /n+N1 /nK file
will do exactly what you need. Just remember that the value of @LINES is an
offset, not line count; an empty file returns -1, a 1-line file returns 0.
The result will be something like this (NOT TESTED):

TAIL /n+N1 /n%@eval[ %@lines[file] - N1 - N2 + 1 ]
--
HTH, Steve

Thanks, this worked like a charm!

I had an idea to scan the file with a DO loop and find the marker that begins the N2 part but this is much easier.