什么是混淆 grep 和 ack？

Question

试试这个：下载https://www.mathworks.com/matlabcentral/fileexchange/19-delta-sigma-toolbox

在解压后的文件夹中，我得到以下结果：

ack --no-heading --no-break --matlab dsexample

Contents.m:56:%   dsexample1      - Discrete-time lowpass/bandpass/quadrature modulator.
Contents.m:57:%   dsexample2      - Continuous-time lowpass modulator.
dsexample1(dsm, LiveDemo); 
fprintf(1,'Done.\n');
adc.sys_cs = sys_cs;

grep -nH -R --include="*.m" dsexample

Contents.m:56:%   dsexample1      - Discrete-time lowpass/bandpass/quadrature modulator.
Contents.m:57:%   dsexample2      - Continuous-time lowpass modulator.
dsexample1(dsm, LiveDemo); d center frequency larger Hinfation Script
fprintf(1,'Done.\n');c = c;formed.s of finite op-amp gain and capacitorased;;n for the input.
adc.sys_cs = sys_cs;snr;seed with CT simulations tora states used in the d-t model_amp); Response');

发生了什么事？

[编辑澄清]：为什么第 3 行结果没有文件名，没有行号？为什么第 4 行和第 5 行的结果甚至不包含dsexample？

注意：使用 ack 3.40 和 grep 2.16

Answer 1

我不应该为这个答案获得任何荣誉 - 这完全是关于行尾。

我多年来一直知道 Windows 行尾 (CR-LF) 和 Linux 行尾（仅限 LF），但我从未听说过 Legacy MAC 行尾（仅限 CR）...后者真的让 ack、grep 感到不安，而且我敢肯定还有很多其他工具。

dos2unix 和 unix2dos 对 Legacy MAC 格式的文件没有影响 - 但是使用这个漂亮的小 endline 工具后，我最终可以为源文件带来一些一致性：

endlines : 129 files converted from :
              - 23 Legacy Mac (CR)
              - 105 Unix (LF)
              - 1 Windows (CR-LF)

现在，ack 和 grep 快乐多了。

Answer 2

让我们看看哪些文件包含dsexample，grep -l不打印内容，只打印文件名：

$ grep -l dsexample *
Contents.m
demoLPandBP.m
dsexample1.m
dsexample2.m

好的，那么，file 表明他们有 CR 行终止符。 （它会说 Windows 文件的“CRLF 行终止符”。）

$ file Contents.m demoLPandBP.m dsexample*
Contents.m:    ASCII text
demoLPandBP.m: ASCII text, with CR line terminators
dsexample1.m:  ASCII text, with CR line terminators
dsexample2.m:  ASCII text, with CR line terminators

与我之前评论的不同，Contents.m 很好。让我们看看另一个，它是如何打印的：

$ grep dsexample demoLPandBP.m 
dsexample1(dsm, LiveDemo); d center frequency larger Hinf

grep 的输出实际上是整个文件，因为grep 不认为普通的 CR 会换行——整个文件是只有一行。如果我们将 CR 更改为 LF，我们会看得更清楚，或者可以只计算行数：

$ grep dsexample demoLPandBP.m | tr '\r' '\n' | wc -l
51

这些是那里最长的行，按顺序排列：

%% 5th-order lowpass with optimized zeros and larger Hinf
dsm.f0 = 1/6;   % Normalized center frequency
dsexample1(dsm, LiveDemo); 

每个结尾都有一个 CR，光标移回行首，部分覆盖之前的输出，所以你得到：

dsexample1(dsm, LiveDemo); d center frequency larger Hinf

（该行的分号后面有一个空格，所以e 也被覆盖了。我检查了。）

有人说dos2unix 无法处理这个问题，而且它们不是 DOS 或 Windows 文件，为什么要这样做。不过，你可以在 Bash 中做这样的事情：

for f in *.m; do
    if [[ $(file "$f") = *"ASCII text, with CR line terminators" ]]; then
        tr '\r' '\n' < "$f" > tmptmptmp &&
        mv tmptmptmp "$f"
    fi
done

我认为只是 .m 文件有问题，因此 *.m 在循环中。那里至少有一个 PDF 文件，我们不想破坏它。虽然在那里检查了file，但即使您只是在* 上运行循环也应该是安全的。

Answer 3

看起来 ack 和 grep 都被文件中的行尾弄糊涂了。在您的文件上运行file *.m。您会看到有些文件有正确的换行符，有些文件有 CR 行终止符。

如果你清理你的行尾，事情应该没问题。