grep main *.c
或者使用您的IDE搜索此函数。它在tar.c中。现在，跳过所有的初始化内容，直到
/* Main command execution. */
在那里，你会看到一个子命令的开关。如果你传递了-x，它会执行这个操作，如果你传递了-c，它会执行那个操作，等等。这是这些命令的分支结构。如果你想知道这些宏是什么，运行
grep EXTRACT_SUBCOMMAND *.h
在这里，你可以看到它们被列在common.h文件中。
在EXTRACT_SUBCOMMAND下面，你会看到一些有趣的东西：
read_and (extract_archive);
read_and()的定义（再次使用grep获得）：
read_and (void (*do_something) (void))
extract_archive。再次使用grep查看，您将看到以下内容： if (prepare_to_extract (current_stat_info.file_name, typeflag, &fun))
{
if (fun && (*fun) (current_stat_info.file_name, typeflag)
&& backup_option)
undo_last_backup ();
}
else
skip_member ();
fun时。 fun再次是一个函数指针，在prepare_to_extract中设置。 fun可能指向extract_file，它执行实际的写入操作。tar和sed这样的程序存在两个问题（当然，这只是我的观点！）。首先，它们都非常古老。这意味着多年来已经有多人对其进行维护，编码风格和性格各异。对于GNU实用程序来说，通常情况下还好，因为它们通常会强制执行合理一致的编码风格，但这仍然是一个问题。另一个问题是它们的可移植性非常高。通常，“可移植性”被视为一件好事，但是当它被推向极端时，这意味着您的代码库中充满了小技巧和技巧，以解决特定硬件和系统中的奇怪错误和边缘情况。对于像tar和sed这样广泛移植的程序来说，这意味着需要考虑很多边缘情况和奇怪的硬件/编译器/操作系统。tar和sed这样成熟的程序，您只能看到会议的结果，但无法实时查看软件设计决策和更改是如何进行的。这只能通过积极维护的软件来实现。yes这样的工具？少于100行的C代码，完全功能、有用且非常基本的GNU软件。我知道有时候浏览 C 代码很混乱，特别是如果你不熟悉它的话。我建议你使用一个工具，它将帮助你浏览函数、符号、宏等。然后找到 main() 函数。
当然，你需要熟悉这些工具，但你不需要成为专家。
理解使用了许多宏、实用函数等代码可能很困难。为了更好地浏览随机 C 或 C++ 软件的代码，我建议采用以下方法，这也是我通常使用的：
安装Qt开发工具和Qt Creator。
下载您想要检查的源代码，并为编译设置它们（通常只需对GNU stuff运行./configure）。
在源目录的根目录中运行qmake -project，以生成用于Qt Creator的Qt .pro文件。
在Qt Creator中打开.pro文件（当它询问时，请不要使用阴影构建）。
为了安全起见，在Qt Creator项目视图中删除默认的构建步骤。 .pro文件仅用于在Qt Creator内导航。
可选：如果您想在Qt Creator下构建、运行/调试，则设置自定义构建和运行步骤。仅导航时不需要。
使用Qt Creator浏览代码。特别注意定位器（kb快捷键Ctrl+K）通过名称查找内容，“跟随光标下的符号”（kb快捷键F2）和“查找用法”（kb快捷键Ctrl-Shift-U）。
我的建议是......对于任何存在已久的代码库都适用......尽可能深入挖掘并首先回溯到其最早的形式；并且要扩展视野，查看其他“sed” - 如UNIX存档中的那些。
或者在BSD存档中：
https://github.com/weiss/original-bsd
（第二个更深入地探讨了早期BSD在其早期提交中的情况。）
GNU页面上的许多“sed” - 但不是全部 - 可以在GNU sed页面上的“下载”下找到一个名为“镜像”的链接：
https://www.gnu.org/software/sed/
版本1.18仍然完好无损。版本1.17也隐含完好无损，因为那里有一个1.17到1.18的差异存在。两个版本都没有所有额外的东西堆积在上面。它更代表了GNU软件在变得混乱之前的样子。
实际上它非常小 - 所有*.c和*.h文件只有8863行。从这里开始。
对我来说，分析任何代码库的过程都会破坏原始代码，并且总是需要大量的重构和重新设计；并且简化来自于更好地编写本地化代码，同时保持或增加其功能。几乎总是由那些只有几年经验（我的意思是：不到20年）的人编写的，因此他们没有完全掌握语言的本地流利度，也没有足够的背景来编写良好的程序。
如果你也这样做，强烈建议你已经有一些测试套件或者添加了一些。例如，在4.2版本软件中就有一个测试套件，尽管它可能会对1.18和4.2之间新增的新功能进行压力测试。只要注意这一点。（因此，可能需要缩小测试套件以适应1.18。）你所做的每一个更改都必须通过你的测试套件进行验证。
你需要具备母语级别的语言流利度......否则，你需要愿意并有能力通过执行此类练习和其他类似练习来获得它。如果你没有足够的经验，你将会遇到一个软墙。你深入挖掘，前进就会变得更加困难。这表明你还不够有经验，没有足够的广度。因此，这个练习成为你学习经验的一部分，你只需要坚持下去。
由于早期版本的日期，您无论如何都需要进行一些重写，以将其提升到标准水平。稍后的版本可以用作此过程的指南。至少应该将其更新到C99，因为这基本上是POSIX的一部分。换句话说，您至少应该跟上当前世纪的步伐！在你满意地重写了基线之后，你可以继续添加后续版本。在GNU的存档中，1.18直接跳到2.05。你需要在两者之间进行“差异”比较，看看所有更改的位置，然后将它们嫁接到你的1.18版本中，以获得你的2.05版本。这将帮助你更好地理解更改所解决的问题以及进行了哪些更改。
在某个时候，你会遇到GNU的Grange Wall。版本2.05直接跳到GNU历史存档中的3.01。一些纠缠开始在3.01版本中出现。因此，我们这里有一个软墙。但是，3.01也有一个早期的测试套件，你应该使用它来测试1.18，而不是4.2的测试套件。
当你遇到 Grunge Wall 时，你将直接看到纠缠的问题，并且你必须决定是否继续前进或放弃它们。我不能告诉你兔子洞的方向，除了 SED 长期以来一直非常好用，大部分甚至都是 POSIX 标准中列出和指定的（即使是当前版本），而版本 3 之前的东西也符合这个目的。
我运行了 diffs，2.05 和 3.01 之间的差异文件有 5000 行。好的。对于正在开发中的代码来说，这基本上很正常，但其中一些可能来自软 Grunge Wall。在 3.01 和 4.2 之间运行 diff，得到一个超过 60000 行的差异文件。你只需要问自己：一个遵守国际标准（POSIX）且不到 10000 行的程序如何能产生 60000 行的差异？答案是：这就是我们所谓的膨胀。因此，在 3.01 和 4.2 之间，你正在见证一个非常常见的代码库问题：膨胀的崛起。
所以，这基本上告诉你了哪个方向（“随波逐流”还是“放弃它”）是兔子洞。我可能会坚持3.01，并简要回顾一下3.01和4.2之间的差异以及更改日志，以获取对更改的概述，然后就此打住，除非为其更改提供的原因是有效的，否则可能会找到另一种编写方式。
我以前做过遗留代码修复，甚至在大多数人的词汇表中没有“遗留”这个词之前就已经这样了，并且很快就能认识到它的标志性迹象。这是人们可能会经历的过程。
我们已经看到一些大型代码库发生了这种情况。实际上，通过Wayland取代X11是一次大规模的遗留代码修复演习。正在进行的GNU's gcc被clang取代也可能被视为其中一个例子。