那些想要计算头部、|、尾部组合的间隔的人是想多了。

下面是如何在不计算任何东西的情况下得到“16224 - 16482”范围:

cat file | head -n +16482 | tail -n +16224

---

解释:

The + instructs the head/tail command to "go up to / start from" (respectively) the specified line number as counted from the beginning of the file. Similarly, a - instructs them to "go up to / start from" (respectively) the specified line number as counted from the end of the file The solution shown above simply uses head first, to 'keep everything up to the top number', and then tail second, to 'keep everything from the bottom number upwards', thus defining our range of interest (with no need to compute an interval).

艾德:使用

ed -s infile <<<'16224,16482p'

-s抑制诊断输出;实际的命令在一个here-string中。具体来说，16224,16482p在所需的行地址范围上运行p (print)命令。

perl -ne 'print if 16224..16482' file.txt > new_file.txt

只是对上面给出的3个解决方案进行了基准测试，这对我来说是可行的:

awk sed “头+尾”

3个解决方案的积分归属:

@boxxar @avandeursen @wds @manveru @sibaz @SOFe @fedorqui“所以停止伤害” @Robin A. Meade

---

我正在使用我在服务器上找到的一个巨大的文件:

# wc fo2debug.1.log
   10421186    19448208 38795491134 fo2debug.1.log

38gb, 1040万行。

是的，我有一个对数问题。:))

---

下注吧!

---

从文件开始获取256行。

# time sed -n '1001,1256p;1256q' fo2debug.1.log | wc -l
256

real    0m0,003s
user    0m0,000s
sys     0m0,004s

# time head -1256 fo2debug.1.log | tail -n +1001 | wc -l
256

real    0m0,003s
user    0m0,006s
sys     0m0,000s

# time awk 'NR==1001, NR==1256; NR==1256 {exit}' fo2debug.1.log | wc -l
256

real    0m0,002s
user    0m0,004s
sys     0m0,000s

Awk赢了。在sed和“头+尾”之间，技术并列第二。

---

在文件的前三分之一处获得256行。

# time sed -n '3473001,3473256p;3473256q' fo2debug.1.log | wc -l
256

real    0m0,265s
user    0m0,242s
sys     0m0,024s

# time head -3473256 fo2debug.1.log | tail -n +3473001 | wc -l
256

real    0m0,308s
user    0m0,313s
sys     0m0,145s

# time awk 'NR==3473001, NR==3473256; NR==3473256 {exit}' fo2debug.1.log | wc -l
256

real    0m0,393s
user    0m0,326s
sys     0m0,068s

Sed赢了。接着是“head+tail”，最后是awk。

---

在文件的第二个三分之一处获得256行。

# time sed -n '6947001,6947256p;6947256q' fo2debug.1.log | wc -l
A256

real    0m0,525s
user    0m0,462s
sys     0m0,064s

# time head -6947256 fo2debug.1.log | tail -n +6947001 | wc -l
256

real    0m0,615s
user    0m0,488s
sys     0m0,423s

# time awk 'NR==6947001, NR==6947256; NR==6947256 {exit}' fo2debug.1.log | wc -l
256

real    0m0,779s
user    0m0,650s
sys     0m0,130s

同样的结果。

Sed赢了。接着是“head+tail”，最后是awk。

---

在文件末尾获得256行。

# time sed -n '10420001,10420256p;10420256q' fo2debug.1.log | wc -l
256

real    1m50,017s
user    0m12,735s
sys     0m22,926s

# time head -10420256 fo2debug.1.log | tail -n +10420001 | wc -l
256

real    1m48,269s
user    0m42,404s
sys     0m51,015s

# time awk 'NR==10420001, NR==10420256; NR==10420256 {exit}' fo2debug.1.log | wc -l
256

real    1m49,106s
user    0m12,322s
sys     0m18,576s

突然，一个转折!

“头+尾”赢了。接着是awk，最后是sed。

---

(几个小时后……)

对不起伙计们!

我上面的分析是做分析时一个基本缺陷的例子。

缺陷在于不深入了解用于分析的资源。

在本例中，我使用了一个日志文件来分析其中特定行数的搜索性能。

使用3种不同的技术，在文件中的不同位置进行搜索，比较每个位置上技术的性能，并检查搜索结果是否随着文件中进行搜索的位置而变化。

我的错误在于假定日志文件中的内容具有某种同质性。

实际情况是，长行更频繁地出现在文件的末尾。

因此，对于一种给定的技术，较长的搜索(接近文件末尾)更好的明显结论可能是有偏见的。事实上，这种技术在处理较长的队伍时可能会更好。还有待证实。

我已经为sed、perl、head+tail和我自己的awk代码编译了一些最高评级的解决方案，并通过管道关注性能，同时使用LC_ALL=C确保所有候选程序以尽可能快的速度运行，并在两者之间分配2秒的睡眠间隔。

差距是显而易见的:

   abs time    awk/app speed ratio
 ----------------------------------
   0.0672 sec :   1.00x mawk-2
   0.0839 sec :   1.25x gnu-sed
   0.1289 sec :   1.92x perl
   0.2151 sec :   3.20x gnu-head+tail

还没有机会测试这些工具的python或BSD变体。

 (fg && fg && fg && fg) 2>/dev/null; 
 echo;
 ( time ( pvE0 < "${m3t}" 
        | LC_ALL=C  mawk2 '

           BEGIN {  
                     _=10420001-(\
                    __=10420256)^(FS="^$") 
           } _<NR { 
                   print

                   if(__==NR) { exit } 
     
     }' ) | pvE9) | tee >(xxh128sum >&2) | LC_ALL=C gwc -lcm | lgp3 ; 
    sleep 2;
    (fg && fg && fg && fg) 2>/dev/null
    echo; 
    ( time ( pvE0 < "${m3t}" 
           | LC_ALL=C gsed -n '10420001,10420256p;10420256q' 
    
     ) | pvE9 ) |  tee >(xxh128sum >&2) |  LC_ALL=C gwc -lcm  | lgp3 ;
     sleep  2; (fg && fg && fg && fg) 2>/dev/null
     echo
    ( time ( pvE0 < "${m3t}" 
           | LC_ALL=C perl -ne 'print if 10420001..10420256'
    
    ) | pvE9 ) |  tee >(xxh128sum >&2) |  LC_ALL=C gwc -lcm | lgp3 ;
    sleep  2; (fg && fg && fg && fg) 2>/dev/null
    echo
    ( time ( pvE0 < "${m3t}" 
           | LC_ALL=C ghead -n +10420256 
           | LC_ALL=C gtail -n +10420001 
    ) | pvE9 ) |  tee >(xxh128sum >&2) |  LC_ALL=C gwc -lcm  | lgp3 ; 


      in0: 1.51GiB 0:00:00 [2.31GiB/s] [2.31GiB/s] [============> ] 81%            
     out9: 42.5KiB 0:00:00 [64.9KiB/s] [64.9KiB/s] [ <=> ]
( pvE 0.1 in0 < "${m3t}" | LC_ALL=C mawk2 ; )
     
   0.43s user 0.36s system 117% cpu 0.672 total
    256   43487   43487

54313365c2e66a48dc1dc33595716cc8  stdin

     out9: 42.5KiB 0:00:00 [51.7KiB/s] [51.7KiB/s] [ <=> ]
      in0: 1.51GiB 0:00:00 [1.84GiB/s] [1.84GiB/s] [==========> ] 81%            

   ( pvE 0.1 in0 < "${m3t}" |LC_ALL=C gsed -n '10420001,10420256p;10420256q'; )  
  
   0.68s user 0.34s system 121% cpu 0.839 total
    256   43487   43487

54313365c2e66a48dc1dc33595716cc8  stdin


      in0: 1.85GiB 0:00:01 [1.46GiB/s] [1.46GiB/s] [=============>] 100%            
     out9: 42.5KiB 0:00:01 [33.5KiB/s] [33.5KiB/s] [  <=> ]

( pvE 0.1 in0 < "${m3t}" | LC_ALL=C perl -ne 'print if 10420001..10420256'; )
     
   1.10s user 0.44s system 119% cpu 1.289 total
    256   43487   43487

54313365c2e66a48dc1dc33595716cc8  stdin

      in0: 1.51GiB 0:00:02 [ 728MiB/s] [ 728MiB/s] [=============> ] 81%            
     out9: 42.5KiB 0:00:02 [19.9KiB/s] [19.9KiB/s] [ <=> ]

 ( pvE 0.1 in0 < "${m3t}" 
   | LC_ALL=C ghead -n +10420256 
   | LC_ALL=C gtail -n ; )  
  
 1.98s user 1.40s system 157% cpu 2.151 total
 256   43487   43487

54313365c2e66a48dc1dc33595716cc8  stdin

站在拳击手的肩膀上，我喜欢这样:

sed -n '<first line>,$p;<last line>q' input

e.g.

sed -n '16224,$p;16482q' input

$表示“最后一行”，因此第一个命令使sed打印从第16224行开始的所有行，第二个命令使sed在打印第16428行之后退出。(在boxxar的解决方案中，为q范围添加1似乎没有必要。)

我喜欢这个变体，因为我不需要两次指定结束行号。而且我认为使用$不会对性能产生不利影响。