标签 历史 下的文章

以前我和我的一些亲戚争论过计算机科学的学位值不值得读。当时我正在上大学,并要决定是不是该主修计算机。我姨和我表姐觉得我不应该主修计算机。她们承认知道如何编程肯定是很有用且对自己有利的一件事,但是她们认为计算机科学现在发展的如此迅速以至于我学的东西几乎马上就过时了。建议我更好是把编程作为辅业,选择一个基础原理可以受用终身的领域主修,比如经济学或物理学。

我知道我姨和我表姐说的不对,并决定主修计算机科学。(对不住啊!)平常人可能会觉得像计算机科学领域和软件工程专业每隔几年就完全和之前不一样了。其原因很容易理解。我们有了个人电脑,然后有了互联网,有了手机,之后还有了机器学习…… 科技总是在更新,支撑科技发展的原理和技能当然也在改变。当然,最惊人的是其实原理的改变竟然如此之小。我敢肯定,大多数人在知道了他们电脑里一些重要的软件的历史是多么久远时他们一定会深感震惊。当然我不是说那些刷版本号的浮夸软件 —— 我电脑上的 Firefox 浏览器副本,可能是我用的最多的软件,可能两周前就更新过。如果你看了比如 grep 的手册页,你就会发现它在 2010 年后就没有过更新了(至少在 MacOS 上如此)。初版 grep 是在 1974 年写就的,那时可以算是计算机世界的侏罗纪了。直到现在,人们(还有程序)仍然依赖 grep 来完成日常工作。

我姨和我表姐认为计算机技术就像一系列日渐精致的沙堡,在潮水抹净沙滩后新的沙堡完全取代旧的。但事实上,在很多领域上,我们都是不断积累能够解决问题的程序。我们可能不得不偶尔修改这些程序以避免软件无法使用,但大多数情况下我们都可以不修改。grep 是一个简单的程序,可以解决一个仍然存在的需求,所以它能够存活下来。 大多数应用程序编程都是在非常高的级别上完成的,它们建立在解决了旧问题的旧程序的金字塔上。 30 年或 40 年前的思路和概念,远非过时,在很多情况下它们依然在您的笔记本电脑上软件中存在着。

我想追溯这样的老程序自第一次写就以来改变了多少回很有趣。 cat 可能是所有 Unix 实用程序中最简单的,因此我们以它为例。Ken Thompson 于 1969 年编写了 cat 的原始实现。如果我告诉别人我的电脑上安装了个来自 1969 年的程序,这准确吗?我们电脑上的程序多大了?

感谢这种这种仓库,我们可以完整的看到 cat 自 1969 年后是如何发展的。我会先聚焦于可以算得上是我的 MacBook 上的 cat 的祖先的 cat 实现。随着我们从 Unix 上的第一版 cat 追踪到现在 MacOS 上的 cat,你会发现,这个程序被重写的次数比你想的还要多 —— 但是直到现在它运行的方式和五十年前多少是完全一致的。

研究 Unix

Ken Thompson 和 Dennis Ritchie 在 PDP 7 上开始写 Unix。那还是 1969 年,C 还没被发明出来,因此所有早期的 Unix 软件都是用 PDP 7 汇编实现的。他们使用的汇编种类是 Unix 特有的,Ken Thompson 在 DEC(PDP 7 的厂商)提供的汇编器之上加了些特性,实现了自己的汇编器。Thompson 的更改在最初的 Unix 程序员手册as(也就是汇编器)条目下均有所记录。

因此,最初的 cat 也是使用 PDP 7 汇编实现的。 我添加了一些注释,试图解释每条指令的作用,但除非你理解 Thompson 在编写汇编器时加的特性,否则程序仍然很难理解。在那些特性中有两个很重要:其一是 ; 这个字符可以在一行中用来分隔多条语句,它多出现于在使用 sys 指令时将系统调用的多个参数放在同一行上。其二是, Thompson 的汇编器支持使用 0 到 9 作为“临时标签”,这是在程序内可以重用的标签。因此。就如 Unix 程序员手册中所说:“对程序员的想象力和汇编程序的符号空间的要求都降低了”。在任何给定的指令内,你都可以使用 nfnb 来引用下一个或最近的临时标签 n。 例如,如果存在标记为 1: 的代码块,你就可以使用指令 jmp 1b 从下游代码跳回该块。 (但是你不使用 jmp 1f 的话就没法从上面的代码跳到这里。)

初版 cat 最有趣的就是它包含着我们应该认识的符号。有一块指令块标记为 getc,还有一个标记为 putc,可以看到这两个符号比 C 标准还古老。第一版的 cat 函数实际上已经包含了这两个函数的实现。该实现做了输入缓存,这样它就不需要一次只读写一个字母。

cat 的第一个版本并没有持续多久。 Ken Thompson 和 Dennis Ritchie 说服贝尔实验室购买了 PDP 11,这样他们就能够继续扩展和改进 Unix。 PDP 11 的指令集和之前不一样,因此必须重写 cat。 我也注释了这个第二版 cat。 它为新的指令集使用新的汇编程序助记符,并利用了 PDP 11 的各种寻址模式。(如果你对源代码中的括号和美元符号感到困惑,那是因为这些符号用于指示不同的寻址模式。)但它也使用 ; 字符和临时标签,和 cat 的第一个版本一样,这意味着当把 as 移植到 PDP 11 上时,必须要保留这些功能。

cat 的第二个版本比第一个版本简单得多。 它也更有 Unix 味儿,它不只是依靠参数列表,一旦没给参数列表,它将从 stdin 读取数据,这也就是今天 cat 仍在做的事情。 你也可以在此版本的 cat 中以 - 为参数,以表示它应该从stdin读取。

在 1973 年,为了准备发布第四版 Unix,大部分代码都用 C 语言重写了。但是 cat 似乎在之后一段时间内并没有使用 C 重写。 cat 的第一个 C 语言实现出现在第七版 Unix 中。 这个实现非常有趣,因为它很简单。 在所有以后的实现中,这个实现和在 K&R 的 C 语言教科书中用作教学示范的理想化 cat 最相似。这个程序的核心就是经典的两行:

while ((c = getc(fi)) != EOF)
 putchar(c);

当然实际代码要比这多一些,额外的代码主要是为了确保你没有在读/写同一个文件。另一个有趣的事情是,cat 的这一版实现只识别一个标志位 -u-u 标志可用于避免缓冲输入和输出,否则 cat 将以 512 字节为块进行输入输出。

BSD

在第七版 Unix 之后,Unix 出现了各种衍生品和分支。 MacOS 建立于 Darwin 之上,而 Darwin 又源自 伯克利软件分发版 Berkeley Software Distribution (BSD),因此 BSD 是我们最感兴趣的 Unix 分支。 BSD 最初只是 Unix 中的实用程序和附加组件的集合,但它最终成为了一个完整的操作系统。直到第四版 BSD,人称 4BSD,为一大堆新标志添加了支持之前,BSD 似乎还是依赖于最初的 cat 实现的。cat4BSD 实现 显然是从原始实现中衍生出来的,尽管它添加了一个新函数来实现由新标志触发的行为。已经在文件中使用的 fflg 变量(用于标记输入是从 stdin 还是文件读取的)的命名约定,被新添加的 nflgbflgvflgsflgeflgtflg 沿袭了下来,这些变量记录了在调用程序时是否使用了这些新标志。这些是最后一批添加到 cat 的命令行标志。如今 cat 的手册页列出了这些标志,没有其他的标志了,至少在 Mac OS 上是如此。 4BSD 于 1980 年发布,因此这套标志已有 38 年历史。

cat 最后一次被完全重写是在 BSD NET/2 上,其目的是通过替换 AT&T 发布的全部 Unix 源代码来规避许可证问题。BSD Net/2 在 1991 年发布。这一版本的 cat 是由 Kevin Fall 重写的。 Kevin Fall 于 1988 年毕业于加州大学伯克利分校并在下一年成为 计算机系统研究组 Computer Systems Research Group (CSRG)的组员,Fall 和我说当时使用 AT&T 代码的 Unix 工具被列在了 CSRG 的墙上,组员需要从中选出他们想要重写的工具; Fall 选了 cat 以及 mknod。 MacOS 系统内自带的 cat 实现源码的最上面还有着他的名字。他的这一版 cat,尽管平淡无奇,在今天还是被无数人使用着。

Fall 的原始 cat 实现 比我们迄今为止看到的版本都要长。 除了支持 -? 帮助标志外,它没有增加任何新功能。 从概念上讲,它与 4BSD 的实现非常相似。 它长是因为 Fall 将实现分为 “原始” 模式和 “加工” 模式。 “原始” 模式是 cat 的经典实现;它一个字符一个字符的打印文件。 “加工” 模式是带有所有 4BSD 命令行选项的 cat。 如此区别不无道理,但这么办也扩充了实现规模,因此乍一看其源码似乎比实际上更复杂。文件末尾还有一个奇特的错误处理函数,进一步地增加了实现的长度。

MacOS

在 2001 年,苹果发布了 MacOS X。这一发布对苹果意义重大。因为苹果用了多年的时间尝试以取代其现有的老旧操作系统(经典的 Mac OS),但是都失败了。 在 Mac OS X 之前苹果两次尝试在内部创建一个新的操作系统,但两者都无疾而终。 最后,苹果收购了史蒂夫·乔布斯的 NeXT 公司,后者开发了一个名为 NeXTSTEP 的操作系统和面向对象编程框架。 苹果将 NeXTSTEP 作为 Mac OS X 的基础。因为 NeXTSTEP 部分基于 BSD,使以 NeXTSTEP 为基础的 Mac OS X 的自然就把 BSD 系的代码直接带入苹果宇宙的中心。

因此,Mac OS X 的非常早期的第一个版本包含了从 NetBSD 项目中提取的 cat实现。如今仍保持开发的 NetBSD 最初是 386BSD 的分支,而后者又直接基于 BSD Net/2。所以 Mac OS X 里面的第一个 cat 的实现就是 Kevin Fall 的 cat。唯一改变的是,Fall 的错误处理函数 err()err.h 提供的 err() 函数取代了。 err.h 是 C 标准库的 BSD 扩展。

之后不久,这里的 cat 的 NetBSD 实现被换成了 FreeBSD 中的 cat 实现。 根据维基百科),苹果在 Mac OS X 10.3(Panther)中开始使用 FreeBSD 的实现而不是 NetBSD 的实现。但根据苹果自己开源的版本,cat 的 Mac OS X 实现在 2007 年发布的 Mac OS X 10.5(Leopard)之前没有被替换。苹果为 Leopard 替换的的 FreeBSD 实现与今天苹果计算机上的实现相同。截至 2018 年,2007 年以来的这个实现仍未被更新或修改。

所以 Mac OS 上的 cat 已经很老了。实际上,这一实现在 2007 年在 MacOS X 上露面两年前就被发布了。 这个 2005 年的修改 在 FreeBSD 的 Github 镜像中可见,是在苹果将其合并入 Mac OS X 前对 FreeBSD 的 cat 实现进行的最后一次更改。所以 Mac OS X 中的实现没有与 FreeBSD 的 cat 实现保持同步,它如今已经 13 岁了。对于软件修改了多少代码才能仍是算是同一软件这一话题有着旷日持久的争论。不过,在这种情况下,源文件自 2005 年以来根本没有变化。

现在 Mac OS 使用的 cat 实现与 Fall 1991 年为 BSD Net/2 版本编写的实现没有什么不同。最大的区别是添加了一个全新的功能来提供 Unix 域套接字支持。FreeBSD 开发人员似乎将 Fall 的 raw_args() 函数和 cook_args() 函数组合成一个名为scanfiles() 的函数。否则,程序的核心就仍是 Fall 的代码。

我问过 Fall 对编写了如今被数以百万计的苹果用户(直接或者间接通过依赖 cat 的某些程序)使用的 cat 实现有何感想。Fall,如今是一位顾问,也是最新版《TCP/IP 详解》的合著者,他说,当人们从了解他对 cat 所做的工作中收获颇丰时,他感到很惊讶。 Fall 在计算机领域有着悠久的职业生涯,曾参与许多备受瞩目的项目,但似乎很多人仍对他在 1989 年重写 cat 的那六个月的工作感到最为兴奋。

百年老程序

在宏伟的发明史中,计算机并不是一项古老的发明。我们已经习惯了百年的照片甚至是百年的视频短片。但是计算机程序不一样 —— 它们代表着高科技和新技术。至少,他们是现代的技术造出来的。随着计算行业的成熟,我们有朝一日会发现自己正在使用有着接近百年历史的程序吗?

计算机硬件可能会发生较大的变化,使得我们也许无法让现在编译的可执行文件在一个世纪后的硬件上运行。也许编程语言设计的进步让未来没有人能理解 C 语言,cat 将来也可能也被别的语言重写很久了。 (尽管 C 已经存在了五十年了,而且它似乎不会很快就被替换掉。)但除此之外,为什么不永远使用我们现在的 cat

我认为 cat 的历史表明,计算机科学中的一些想法确实非常持久。事实上,对于 cat,这个想法和程序本身都很古老。不准确地说,我的电脑上的 cat 来自 1969 年。但我也可以说我的计算机上的 cat 来自1989 年,当时 Fall 写了他的 cat 实现。许多其他软件也同样古老。因此,也许我们不应该把计算机科学和软件开发视为不断破坏现状和发明新事物的领域。我们的计算机系统是由诸多历史文物构建的。有时,我们可能会花费更多时间在理解和维护这些历史文物上,而不是花在编写新代码上。

如果你喜欢本文,你可能更喜欢两周来一篇更新!在推特上关注 @TwoBitHistory 或者订阅这个 RSS 源 以保证接受到新的文章。


via: https://twobithistory.org/2018/11/12/cat.html

作者:Two-Bit History 选题:lujun9972 译者:name1e5s 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

用强大的 history 命令使你的命令行提示符更有效率。

随着我在终端中花费越来越多的时间,我感觉就像在不断地寻找新的命令,以使我的日常任务更加高效。GNU 的 history 命令是一个真正改变我日常工作的命令。

GNU history 命令保存了从该终端会话运行的所有其他命令的列表,然后允许你重放或者重用这些命令,而不用重新输入它们。如果你是一个老玩家,你知道 history 的力量,但对于我们这些半吊子或新手系统管理员来说, history 是一个立竿见影的生产力增益。

历史 101

要查看命令历史,请在 Linux 中打开终端程序,然后输入:

$ history

这是我得到的响应:

1  clear
2  ls -al
3  sudo dnf update -y
4  history

history 命令显示自开始会话后输入的命令列表。 history 有趣的地方是你可以使用以下命令重放任意一个命令:

$ !3

提示符中的 !3 告诉 shell 重新运行历史列表中第 3 个命令。我还可以输入以下命令来使用:

linuser@my_linux_box: !sudo dnf

history 将搜索与你提供的模式相匹配的最后一个命令,并运行它。

搜索历史

你还可以输入 !! 重新运行命令历史中的最后一条命令。而且,通过与grep 配对,你可以搜索与文本模式相匹配的命令,或者通过与 tail 一起使用,你可以找到你最后几条执行的命令。例如:

$ history | grep dnf
3  sudo dnf update -y
5  history | grep dnf
$ history | tail -n 3
4  history
5  history | grep dnf
6  history | tail -n 3

另一种实现这个功能的方法是输入 Ctrl-R 来调用你的命令历史记录的递归搜索。输入后,提示变为:

(reverse-i-search)`':

现在你可以开始输入一个命令,并且会显示匹配的命令,按回车键执行。

更改已执行的命令

history 还允许你使用不同的语法重新运行命令。例如,如果我想改变我以前的命令 history | grep dnfhistory | grep ssh,我可以在提示符下执行以下命令:

$ ^dnf^ssh^

history 将重新运行该命令,但用 ssh 替换 dnf,并执行它。

删除历史

有时你想要删除一些或全部的历史记录。如果要删除特定命令,请输入 history -d <行号>。要清空历史记录,请执行 history -c

历史文件存储在一个你可以修改的文件中。bash shell 用户可以在他们的家目录下找到 .bash_history

下一步

你可以使用 history 做许多其他事情:

  • 将历史缓冲区设置为一定数量
  • 记录历史中每行的日期和时间
  • 防止某些命令被记录在历史记录中

有关 history 命令的更多信息和其他有趣的事情,请参考 GNU Bash 手册


via: https://opensource.com/article/18/6/history-command

作者:Steve Morris 选题:lujun9972 译者:geekpi 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

fcFix Commands 的缩写)是个 shell 内置命令,用于在交互式 shell 里列出、编辑和执行最近输入的命令。你可以用你喜欢的编辑器编辑最近的命令并再次执行,而不用把它们整个重新输入一遍。除了可以避免重复输入又长又复杂的命令,它对修正拼写错误来说也很有用。因为是 shell 内置命令,大多 shell 都包含它,比如 Bash 、 Zsh 、 Ksh 等。在这篇短文中,我们来学一学在 Linux 中使用 fc 命令。

fc 命令教程及示例

列出最近执行的命令

执行不带其它参数的 fc -l 命令,它会列出最近 16 个命令。

$ fc -l
507 fish
508 fc -l
509 sudo netctl restart wlp9s0sktab
510 ls -l
511 pwd
512 uname -r
513 uname -a
514 touch ostechnix.txt
515 vi ostechnix.txt
516 echo "Welcome to OSTechNix"
517 sudo apcman -Syu
518 sudo pacman -Syu
519 more ostechnix.txt
520 wc -l ostechnix.txt
521 cat ostechnix.txt
522 clear

-r 选项用于将输出反向排序。

$ fc -lr

-n 选项用于隐藏行号。

$ fc -ln
 nano ~/.profile
 source ~/.profile
 source ~/.profile
 fc -ln
 fc -l
 sudo netctl restart wlp9s0sktab
 ls -l
 pwd
 uname -r
 uname -a
 echo "Welcome to OSTechNix"
 sudo apcman -Syu
 cat ostechnix.txt
 wc -l ostechnix.txt
 more ostechnix.txt
 clear

这样行号就不再显示了。

如果想以某个命令开始,只需在 -l 选项后面加上行号即可。比如,要显示行号 520 至最近的命令,可以这样:

$ fc -l 520
520 ls -l
521 pwd
522 uname -r
523 uname -a
524 echo "Welcome to OSTechNix"
525 sudo apcman -Syu
526 cat ostechnix.txt
527 wc -l ostechnix.txt
528 more ostechnix.txt
529 clear
530 fc -ln
531 fc -l

要列出一段范围内的命令,将始、末行号作为 fc -l 的参数即可,比如 520 至 525:

$ fc -l 520 525
520 ls -l
521 pwd
522 uname -r
523 uname -a
524 echo "Welcome to OSTechNix"
525 sudo apcman -Syu

除了使用行号,我们还可以使用字符。比如,要列出最近一个 pwd 至最近一个命令之间的所有命令,只需要像下面这样使用起始字母即可:

$ fc -l p
521 pwd
522 uname -r
523 uname -a
524 echo "Welcome to OSTechNix"
525 sudo apcman -Syu
526 cat ostechnix.txt
527 wc -l ostechnix.txt
528 more ostechnix.txt
529 clear
530 fc -ln
531 fc -l
532 fc -l 520
533 fc -l 520 525
534 fc -l 520
535 fc -l 522
536 fc -l l

要列出所有 pwdmore 之间的命令,你可以都使用起始字母,像这样:

$ fc -l p m

或者,使用开始命令的首字母以及结束命令的行号:

$ fc -l p 528

或者都使用行号:

$ fc -l 521 528

这三个命令都显示一样的结果。

编辑并执行上一个命令

我们经常敲错命令,这时你可以用默认编辑器修正拼写错误并执行而不用将命令重新再敲一遍。

编辑并执行上一个命令:

$ fc

这会在默认编辑器里载入上一个命令。

你可以看到,我上一个命令是 fc -l。你可以随意修改,它会在你保存退出编辑器时自动执行。这在命令或参数又长又复杂时很有用。需要注意的是,它同时也可能是毁灭性的。比如,如果你的上一个命令是危险的 rm -fr <some-path>,当它自动执行时你可能丢掉你的重要数据。所以,小心谨慎对待每一个命令。

更改默认编辑器

另一个有用的选项是 -e ,它可以用来为 fc 命令选择不同的编辑器。比如,如果我们想用 nano 来编辑上一个命令:

$ fc -e nano

这个命令会打开 nano 编辑器(而不是默认编辑器)编辑上一个命令。

如果你觉得用 -e 选项太麻烦,你可以修改你的默认编辑器,只需要将环境变量 FCEDIT 设为你想要让 fc 使用的编辑器名称即可。

比如,要把 nano 设为默认编辑器,编辑你的 ~/.profile 或其他初始化文件: (LCTT 译注:如果 ~/.profile 不存在可自己创建;如果使用的是 bash ,可以编辑 ~/.bash_profile

$ vi ~/.profile

添加下面一行:

FCEDIT=nano
# LCTT译注:如果在子 shell 中会用到 fc ,最好在这里 export FCEDIT

你也可以使用编辑器的完整路径:

FCEDIT=/usr/local/bin/emacs

输入 :wq 保存退出。要使改动立即生效,运行以下命令:

$ source ~/.profile

现在再输入 fc 就可以使用 nano 编辑器来编辑上一个命令了。

不编辑而直接执行上一个命令

我们现在知道 fc 命令不带任何参数的话会将上一个命令载入编辑器。但有时你可能不想编辑,仅仅是想再次执行上一个命令。这很简单,在末尾加上连字符(-)就可以了:

$ echo "Welcome to OSTechNix"
Welcome to OSTechNix

$ fc -e -
echo "Welcome to OSTechNix"
Welcome to OSTechNix

如你所见,fc 带了 -e 选项,但并没有编辑上一个命令(例中的 echo " Welcome to OSTechNix")。

需要注意的是,有些选项仅对指定 shell 有效。比如下面这些选项可以用在 zsh 中,但在 Bash 或 Ksh 中则不能用。

显示命令的执行时间

想要知道命令是在什么时候执行的,可以用 -d 选项:

fc -ld
1 18:41 exit
2 18:41 clear
3 18:42 fc -l
4 18:42 sudo netctl restart wlp9s0sktab
5 18:42 ls -l
6 18:42 pwd
7 18:42 uname -r
8 18:43 uname -a
9 18:43 cat ostechnix.txt
10 18:43 echo "Welcome to OSTechNix"
11 18:43 more ostechnix.txt
12 18:43 wc -l ostechnix.txt
13 18:43 cat ostechnix.txt
14 18:43 clear
15 18:43 fc -l

这样你就可以查看最近命令的具体执行时间了。

使用选项 -f ,可以为每个命令显示完整的时间戳。

 fc -lf
 1 4/5/2018 18:41 exit
 2 4/5/2018 18:41 clear
 3 4/5/2018 18:42 fc -l
 4 4/5/2018 18:42 sudo netctl restart wlp9s0sktab
 5 4/5/2018 18:42 ls -l
 6 4/5/2018 18:42 pwd
 7 4/5/2018 18:42 uname -r
 8 4/5/2018 18:43 uname -a
 9 4/5/2018 18:43 cat ostechnix.txt
 10 4/5/2018 18:43 echo "Welcome to OSTechNix"
 11 4/5/2018 18:43 more ostechnix.txt
 12 4/5/2018 18:43 wc -l ostechnix.txt
 13 4/5/2018 18:43 cat ostechnix.txt
 14 4/5/2018 18:43 clear
 15 4/5/2018 18:43 fc -l
 16 4/5/2018 18:43 fc -ld

当然,欧洲的老乡们还可以使用 -E 选项来显示欧洲时间格式。

 fc -lE
 2 5.4.2018 18:41 clear
 3 5.4.2018 18:42 fc -l
 4 5.4.2018 18:42 sudo netctl restart wlp9s0sktab
 5 5.4.2018 18:42 ls -l
 6 5.4.2018 18:42 pwd
 7 5.4.2018 18:42 uname -r
 8 5.4.2018 18:43 uname -a
 9 5.4.2018 18:43 cat ostechnix.txt
 10 5.4.2018 18:43 echo "Welcome to OSTechNix"
 11 5.4.2018 18:43 more ostechnix.txt
 12 5.4.2018 18:43 wc -l ostechnix.txt
 13 5.4.2018 18:43 cat ostechnix.txt
 14 5.4.2018 18:43 clear
 15 5.4.2018 18:43 fc -l
 16 5.4.2018 18:43 fc -ld
 17 5.4.2018 18:49 fc -lf

fc 用法总结

  • 当不带任何参数时,fc 将上一个命令载入默认编辑器。
  • 当带一个数字作为参数时,fc 将数字指定的命令载入默认编辑器。
  • 当带一个字符作为参数时,fc 将最近一个以指定字符开头的命令载入默认编辑器。
  • 当有两个参数时,它们分别指定需要列出的命令范围的开始和结束。

更多细节,请参考 man 手册。

$ man fc

好了,今天就这些。希望这篇文章能帮助到你。更多精彩内容,敬请期待!


via: https://www.ostechnix.com/the-fc-command-tutorial-with-examples-for-beginners/

作者:SK 选题:lujun9972 译者:Dotcra 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

在你的日常工作中,不可能每天都从头开始去开发一个新的应用程序。而真实的情况是,在日常工作中,我们大多数时候所面对的都是遗留下来的一个代码库,去修改一些特性的内容或者现存的一些代码行,这是我们在日常工作中很重要的一部分。而这也就是分布式版本控制系统 git 的价值所在。现在,我们来深入了解怎么去使用 git 的历史以及如何很轻松地去浏览它的历史。

Git 历史

首先和最重要的事是,什么是 git 历史?正如其名字一样,它是一个 git 仓库的提交历史。它包含一堆提交信息,其中有它们的作者的名字、该提交的哈希值以及提交日期。查看一个 git 仓库历史的方法很简单,就是一个 git log 命令。

旁注:为便于本文的演示,我们使用 Ruby on Rails 的仓库的 master 分支。之所以选择它的理由是因为,Rails 有良好的 git 历史,漂亮的提交信息、引用以及对每个变更的解释。如果考虑到代码库的大小、维护者的年龄和数量,Rails 肯定是我见过的最好的仓库。当然了,我并不是说其它的 git 仓库做的不好,它只是我见过的比较好的一个仓库。

那么,回到 Rails 仓库。如果你在 Ralis 仓库上运行 git log。你将看到如下所示的输出:

commit 66ebbc4952f6cfb37d719f63036441ef98149418
Author: Arthur Neves <[email protected]>
Date:   Fri Jun 3 17:17:38 2016 -0400

    Dont re-define class SQLite3Adapter on test

    We were declaring  in a few tests, which depending of    the order load will cause an error, as the super class could change.

    see https://github.com/rails/rails/commit/ac1c4e141b20c1067af2c2703db6e1b463b985da#commitcomment-17731383

commit 755f6bf3d3d568bc0af2c636be2f6df16c651eb1
Merge: 4e85538 f7b850e
Author: Eileen M. Uchitelle <[email protected]>
Date:   Fri Jun 3 10:21:49 2016 -0400

    Merge pull request #25263 from abhishekjain16/doc_accessor_thread

    [skip ci] Fix grammar

commit f7b850ec9f6036802339e965c8ce74494f731b4a
Author: Abhishek Jain <[email protected]>
Date:   Fri Jun 3 16:49:21 2016 +0530

    [skip ci] Fix grammar

commit 4e85538dddf47877cacc65cea6c050e349af0405
Merge: 082a515 cf2158c
Author: Vijay Dev <[email protected]>
Date:   Fri Jun 3 14:00:47 2016 +0000

    Merge branch 'master' of github.com:rails/docrails

    Conflicts:
        guides/source/action_cable_overview.md

commit 082a5158251c6578714132e5c4f71bd39f462d71
Merge: 4bd11d4 3bd30d9
Author: Yves Senn <[email protected]>
Date:   Fri Jun 3 11:30:19 2016 +0200

    Merge pull request #25243 from sukesan1984/add_i18n_validation_test

    Add i18n_validation_test

commit 4bd11d46de892676830bca51d3040f29200abbfa
Merge: 99d8d45 e98caf8
Author: Arthur Nogueira Neves <[email protected]>
Date:   Thu Jun 2 22:55:52 2016 -0400

    Merge pull request #25258 from alexcameron89/master

    [skip ci] Make header bullets consistent in engines.md

commit e98caf81fef54746126d31076c6d346c48ae8e1b
Author: Alex Kitchens <[email protected]>
Date:   Thu Jun 2 21:26:53 2016 -0500

    [skip ci] Make header bullets consistent in engines.md

正如你所见,git log 展示了提交的哈希、作者及其 email 以及该提交创建的日期。当然,git 输出的可定制性很强大,它允许你去定制 git log 命令的输出格式。比如说,我们只想看提交信息的第一行,我们可以运行 git log --oneline,它将输出一个更紧凑的日志:

66ebbc4 Dont re-define class SQLite3Adapter on test
755f6bf Merge pull request #25263 from abhishekjain16/doc_accessor_thread
f7b850e [skip ci] Fix grammar4e85538 Merge branch 'master' of github.com:rails/docrails
082a515 Merge pull request #25243 from sukesan1984/add_i18n_validation_test
4bd11d4 Merge pull request #25258 from alexcameron89/master
e98caf8 [skip ci] Make header bullets consistent in engines.md
99d8d45 Merge pull request #25254 from kamipo/fix_debug_helper_test
818397c Merge pull request #25240 from matthewd/reloadable-channels
2c5a8ba Don't blank pad day of the month when formatting dates
14ff8e7 Fix debug helper test

如果你想看 git log 的全部选项,我建议你去查阅 git log 的 man 页面,你可以在一个终端中输入 man git-log 或者 git help log 来获得。

小提示:如果你觉得 git log 看起来太恐怖或者过于复杂,或者你觉得看它太无聊了,我建议你去寻找一些 git 的 GUI 或命令行工具。在之前,我使用过 GitX ,我觉得它很不错,但是,由于我看命令行更“亲切”一些,在我尝试了 tig 之后,就再也没有去用过它。

寻找尼莫

现在,我们已经知道了关于 git log 命令的一些很基础的知识之后,我们来看一下,在我们的日常工作中如何使用它更加高效地浏览历史。

假如,我们怀疑在 String#classify 方法中有一个预期之外的行为,我们希望能够找出原因,并且定位出实现它的代码行。

为达到上述目的,你可以使用的第一个命令是 git grep,通过它可以找到这个方法定义在什么地方。简单来说,这个命令输出了匹配特定模式的那些行。现在,我们来找出定义它的方法,它非常简单 —— 我们对 def classify 运行 grep,然后看到的输出如下:

➜  git grep 'def classify'

activesupport/lib/active_support/core_ext/string/inflections.rb:    def classifyactivesupport/lib/active_support/inflector/methods.rb:    def classify(table_name)tools/profile:    def classify

现在,虽然我们已经看到这个方法是在哪里创建的,但是,并不能够确定它是哪一行。如果,我们在 git grep 命令上增加 -n 标志,git 将提供匹配的行号:

➜  git grep -n 'def classify'

activesupport/lib/active_support/core_ext/string/inflections.rb:205:  def classifyactivesupport/lib/active_support/inflector/methods.rb:186:    def classify(table_name)tools/profile:112:    def classify

更好看了,是吧?考虑到上下文,我们可以很轻松地找到,这个方法在 activesupport/lib/active_support/core_ext/string/inflections.rb 的第 205 行的 classify 方法,它看起来像这样,是不是很容易?

# Creates a class name from a plural table name like Rails does for table names to models.
# Note that this returns a string and not a class. (To convert to an actual class
# follow +classify+ with +constantize+.)
#
#   'ham_and_eggs'.classify # => "HamAndEgg"
#   'posts'.classify        # => "Post"
    def classify
        ActiveSupport::Inflector.classify(self)
    end

尽管我们找到的这个方法是在 String 上的一个常见的调用,它调用了 ActiveSupport::Inflector 上的另一个同名的方法。根据之前的 git grep 的结果,我们可以很轻松地发现结果的第二行, activesupport/lib/active_support/inflector/methods.rb 在 186 行上。我们正在寻找的方法是这样的:

# Creates a class name from a plural table name like Rails does for table
# names to models. Note that this returns a string and not a Class (To
# convert to an actual class follow +classify+ with constantize).
#
#   classify('ham_and_eggs') # => "HamAndEgg"
#   classify('posts')        # => "Post"
#
# Singular names are not handled correctly:
#
#   classify('calculus')     # => "Calculus"
def classify(table_name)
    # strip out any leading schema name
    camelize(singularize(table_name.to_s.sub(/.*\./, ''.freeze)))
end

酷!考虑到 Rails 仓库的大小,我们借助 git grep 找到它,用时都没有超越 30 秒。

那么,最后的变更是什么?

现在,我们已经找到了所要找的方法,现在,我们需要搞清楚这个文件所经历的变更。由于我们已经知道了正确的文件名和行数,我们可以使用 git blame。这个命令展示了一个文件中每一行的最后修订者和修订的内容。我们来看一下这个文件最后的修订都做了什么:

git blame activesupport/lib/active_support/inflector/methods.rb

虽然我们得到了这个文件每一行的最后的变更,但是,我们更感兴趣的是对特定方法(176 到 189 行)的最后变更。让我们在 git blame 命令上增加一个选项,让它只显示那些行的变化。此外,我们将在命令上增加一个 -s (忽略)选项,去跳过那一行变更时的作者名字和修订(提交)的时间戳:

git blame -L 176,189 -s activesupport/lib/active_support/inflector/methods.rb

9fe8e19a 176)   #Creates a class name from a plural table name like Rails does for table
5ea3f284 177)   # names to models. Note that this returns a string and not a Class (To
9fe8e19a 178)   # convert to an actual class follow +classify+ with #constantize).
51cd6bb8 179)   #
6d077205 180)   #   classify('ham_and_eggs') # => "HamAndEgg"
9fe8e19a 181)   #   classify('posts')        # => "Post"
51cd6bb8 182)   #
51cd6bb8 183)   # Singular names are not handled correctly:
5ea3f284 184)   #
66d6e7be 185)   #   classify('calculus')     # => "Calculus"
51cd6bb8 186)   def classify(table_name)
51cd6bb8 187)     # strip out any leading schema name
5bb1d4d2 188)     camelize(singularize(table_name.to_s.sub(/.*\./, ''.freeze)))
51cd6bb8 189)     end

现在,git blame 命令的输出展示了指定行的全部内容以及它们各自的修订。让我们来看一下指定的修订,换句话说就是,每个变更都修订了什么,我们可以使用 git show 命令。当指定一个修订哈希(像 66d6e7be)作为一个参数时,它将展示这个修订的全部内容。包括作者名字、时间戳以及完整的修订内容。我们来看一下 188 行最后的修订都做了什么?

git show 5bb1d4d2

你亲自做实验了吗?如果没有做,我直接告诉你结果,这个令人惊叹的 提交 是由 Schneems 完成的,他通过使用 frozen 字符串做了一个非常有趣的性能优化,这在我们当前的场景中是非常有意义的。但是,由于我们在这个假设的调试会话中,这样做并不能告诉我们当前问题所在。因此,我们怎么样才能够通过研究来发现,我们选定的方法经过了哪些变更?

搜索日志

现在,我们回到 git 日志,现在的问题是,怎么能够看到 classify 方法经历了哪些修订?

git log 命令非常强大,因此它提供了非常多的列表选项。我们尝试使用 -p 选项去看一下保存了这个文件的 git 日志内容,这个选项的意思是在 git 日志中显示这个文件的完整补丁:

git log -p activesupport/lib/active_support/inflector/methods.rb

这将给我们展示一个很长的修订列表,显示了对这个文件的每个修订。但是,正如下面所显示的,我们感兴趣的是对指定行的修订。对命令做一个小的修改,只显示我们希望的内容:

git log -L 176,189:activesupport/lib/active_support/inflector/methods.rb

git log 命令接受 -L 选项,它用一个行的范围和文件名做为参数。它的格式可能有点奇怪,格式解释如下:

git log -L <start-line>,<end-line>:<path-to-file>

当我们运行这个命令之后,我们可以看到对这些行的一个修订列表,它将带我们找到创建这个方法的第一个修订:

commit 51xd6bb829c418c5fbf75de1dfbb177233b1b154
Author: Foo Bar <[email protected]>
Date:   Tue Jun 7 19:05:09 2011 -0700

    Refactor

diff--git a/activesupport/lib/active_support/inflector/methods.rb b/activesupport/lib/active_support/inflector/methods.rb
--- a/activesupport/lib/active_support/inflector/methods.rb
+++ b/activesupport/lib/active_support/inflector/methods.rb
@@ -58,0 +135,14 @@
+    # Create a class name from a plural table name like Rails does for table names to models.
+    # Note that this returns a string and not a Class. (To convert to an actual class
+    # follow +classify+ with +constantize+.)
+    #
+    # Examples:
+    #   "egg_and_hams".classify # => "EggAndHam"
+    #   "posts".classify        # => "Post"
+    #
+    # Singular names are not handled correctly:
+    #   "business".classify     # => "Busines"
+    def classify(table_name)
+      # strip out any leading schema name
+      camelize(singularize(table_name.to_s.sub(/.*\./, '')))
+    end

现在,我们再来看一下 —— 它是在 2011 年提交的。git 可以让我们重回到这个时间。这是一个很好的例子,它充分说明了足够的提交信息对于重新了解当时的上下文环境是多么的重要,因为从这个提交信息中,我们并不能获得足够的信息来重新理解当时的创建这个方法的上下文环境,但是,话说回来,你不应该对此感到恼怒,因为,你看到的这些项目,它们的作者都是无偿提供他们的工作时间和精力来做开源工作的。(向开源项目贡献者致敬!)

回到我们的正题,我们并不能确认 classify 方法最初实现是怎么回事,考虑到这个第一次的提交只是一个重构。现在,如果你认为,“或许、有可能、这个方法不在 176 行到 189 行的范围之内,那么就你应该在这个文件中扩大搜索范围”,这样想是对的。我们看到在它的修订提交的信息中提到了“重构”这个词,它意味着这个方法可能在那个文件中是真实存在的,而且是在重构之后它才存在于那个行的范围内。

但是,我们如何去确认这一点呢?不管你信不信,git 可以再次帮助你。git log 命令有一个 -S 选项,它可以传递一个特定的字符串作为参数,然后去查找代码变更(添加或者删除)。也就是说,如果我们执行 git log -S classify 这样的命令,我们可以看到所有包含 classify 字符串的变更行的提交。

如果你在 Ralis 仓库上运行上述命令,首先你会发现这个命令运行有点慢。但是,你应该会发现 git 实际上解析了在那个仓库中的所有修订来匹配这个字符串,其实它的运行速度是非常快的。在你的指尖下 git 再次展示了它的强大之处。因此,如果去找关于 classify 方法的第一个修订,我们可以运行如下的命令:

git log -S 'def classify'

它将返回所有这个方法的引用和修改的地方。如果你一直往下看,你将看到日志中它的最后的提交:

commit db045dbbf60b53dbe013ef25554fd013baf88134
Author: David Heinemeier Hansson <[email protected]>
Date:   Wed Nov 24 01:04:44 2004 +0000
    Initial
    git-svn-id: http://svn-commit.rubyonrails.org/rails/trunk@4 5ecf4fe2-1ee6-0310-87b1-e25e094e27de

很酷!是吧?它初次被提交到 Rails,是由 DHH 在一个 svn 仓库上做的!这意味着 classify 大概在一开始就被提交到了 Rails 仓库。现在,我们去看一下这个提交的所有变更信息,我们运行如下的命令:

git show db045dbbf60b53dbe013ef25554fd013baf88134

非常好!我们终于找到它的根源了。现在,我们使用 git log -S 'def classify' 的输出,结合 git log -L 命令来跟踪这个方法都发生了哪些变更。

下次见

当然,我们并没有真的去修改任何 bug,因为我们只是去尝试使用一些 git 命令,来演示如何查看 classify 方法的演变历史。但是不管怎样,git 是一个非常强大的工具,我们必须学好它、用好它。我希望这篇文章可以帮助你掌握更多的关于如何使用 git 的知识。

你喜欢这些内容吗?


作者简介:

后端工程师,对 Ruby、Go、微服务、构建弹性架构来解决大规模部署带来的挑战很感兴趣。我在阿姆斯特丹的 Rails Girls 担任顾问,维护着一个小而精的列表,并且经常为开源做贡献。

那个列表是我写的关于软件开发、编程语言以及任何我感兴趣的东西。


via: https://ieftimov.com/learn-your-tools-navigating-git-history

作者:Ilija Eftimov 译者:qhwdw 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

我们都对 history 命令很熟悉。它将终端上 bash 执行过的所有命令存储到 .bash_history 文件中,来帮助我们复查用户之前执行过的命令。

默认情况下 history 命令直接显示用户执行的命令而不会输出运行命令时的日期和时间,即使 history 命令记录了这个时间。

运行 history 命令时,它会检查一个叫做 HISTTIMEFORMAT 的环境变量,这个环境变量指明了如何格式化输出 history 命令中记录的这个时间。

若该值为 null 或者根本没有设置,则它跟大多数系统默认显示的一样,不会显示日期和时间。

HISTTIMEFORMAT 使用 strftime 来格式化显示时间(strftime - 将日期和时间转换为字符串)。history 命令输出日期和时间能够帮你更容易地追踪问题。

  • %T: 替换为时间(%H:%M:%S)。
  • %F: 等同于 %Y-%m-%d (ISO 8601:2000 标准日期格式)。

下面是 history 命令默认的输出。

# history
 1 yum install -y mysql-server mysql-client
 2 service mysqld start
 3 sysdig proc.name=sshd
 4 sysdig -c topprocs_net
 5 sysdig proc.name=sshd
 6 sysdig proc.name=sshd | more
 7 sysdig fd.name=/var/log/auth.log | more
 8 sysdig fd.name=/var/log/mysqld.log
 9 sysdig -cl
 10 sysdig -i httplog
 11 sysdig -i proc_exec_time
 12 sysdig -i topprocs_cpu
 13 sysdig -c topprocs_cpu
 14 sysdig -c tracers_2_statsd
 15 sysdig -c topfiles_bytes
 16 sysdig -c topprocs_cpu
 17 sysdig -c topprocs_cpu "fd.name contains sshd"
 18 sysdig -c topprocs_cpu "proc.name contains sshd"
 19 csysdig
 20 sysdig -c topprocs_cpu
 21 rpm --import https://s3.amazonaws.com/download.draios.com/DRAIOS-GPG-KEY.public
 22 curl -s -o /etc/yum.repos.d/draios.repo http://download.draios.com/stable/rpm/draios.repo
 23 yum install -y epel-release
 24 yum update
 25 yum makecache
 26 yum -y install kernel-devel-$(uname -r)
 27 yum -y install sysdig
 28 sysdig
 29 yum install httpd mysql
 30 service httpd start

根据需求,有三种不同的设置环境变量的方法。

  • 临时设置当前用户的环境变量
  • 永久设置当前/其他用户的环境变量
  • 永久设置所有用户的环境变量

注意: 不要忘了在最后那个单引号前加上空格,否则输出会很混乱的。

方法 1:

运行下面命令为为当前用户临时设置 HISTTIMEFORMAT 变量。这会一直生效到下次重启。

# export HISTTIMEFORMAT='%F %T '

方法 2:

HISTTIMEFORMAT 变量加到 .bashrc.bash_profile 文件中,让它永久生效。

# echo 'HISTTIMEFORMAT="%F %T "' >> ~/.bashrc
或
# echo 'HISTTIMEFORMAT="%F %T "' >> ~/.bash_profile

运行下面命令来让文件中的修改生效。

# source ~/.bashrc
或
# source ~/.bash_profile

方法 3:

HISTTIMEFORMAT 变量加入 /etc/profile 文件中,让它对所有用户永久生效。

# echo 'HISTTIMEFORMAT="%F %T "' >> /etc/profile

运行下面命令来让文件中的修改生效。

# source /etc/profile

输出结果为:

# history
 1 2017-08-16 15:30:15 yum install -y mysql-server mysql-client
 2 2017-08-16 15:30:15 service mysqld start
 3 2017-08-16 15:30:15 sysdig proc.name=sshd
 4 2017-08-16 15:30:15 sysdig -c topprocs_net
 5 2017-08-16 15:30:15 sysdig proc.name=sshd
 6 2017-08-16 15:30:15 sysdig proc.name=sshd | more
 7 2017-08-16 15:30:15 sysdig fd.name=/var/log/auth.log | more
 8 2017-08-16 15:30:15 sysdig fd.name=/var/log/mysqld.log
 9 2017-08-16 15:30:15 sysdig -cl
 10 2017-08-16 15:30:15 sysdig -i httplog
 11 2017-08-16 15:30:15 sysdig -i proc_exec_time
 12 2017-08-16 15:30:15 sysdig -i topprocs_cpu
 13 2017-08-16 15:30:15 sysdig -c topprocs_cpu
 14 2017-08-16 15:30:15 sysdig -c tracers_2_statsd
 15 2017-08-16 15:30:15 sysdig -c topfiles_bytes
 16 2017-08-16 15:30:15 sysdig -c topprocs_cpu
 17 2017-08-16 15:30:15 sysdig -c topprocs_cpu "fd.name contains sshd"
 18 2017-08-16 15:30:15 sysdig -c topprocs_cpu "proc.name contains sshd"
 19 2017-08-16 15:30:15 csysdig
 20 2017-08-16 15:30:15 sysdig -c topprocs_cpu
 21 2017-08-16 15:30:15 rpm --import https://s3.amazonaws.com/download.draios.com/DRAIOS-GPG-KEY.public
 22 2017-08-16 15:30:15 curl -s -o /etc/yum.repos.d/draios.repo http://download.draios.com/stable/rpm/draios.repo
 23 2017-08-16 15:30:15 yum install -y epel-release
 24 2017-08-16 15:30:15 yum update
 25 2017-08-16 15:30:15 yum makecache
 26 2017-08-16 15:30:15 yum -y install kernel-devel-$(uname -r)
 27 2017-08-16 15:30:15 yum -y install sysdig
 28 2017-08-16 15:30:15 sysdig
 29 2017-08-16 15:30:15 yum install httpd mysql
 30 2017-08-16 15:30:15 service httpd start

via: https://www.2daygeek.com/display-date-time-linux-bash-history-command/

作者:2daygeek 译者:lujun9972 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

Yum 是 RHEL/CentOS 的一个基于 rpm 的交互式高级包管理器,用户可以用它来安装新的软件包、卸载或清除旧的/不需要的软件包。它可以自动运行系统更新,并执行依赖分析,对已安装的或可用的软件包进行查询等等。

在本文中,我们将解释如何查看 Yum 事务的历史记录,以便于了解有关安装的软件包以及从系统中所卸载/清除软件包的信息。

推荐阅读: 20 条关于 Linux 软件包管理的 Yum 命令

以下是一些如何使用 Yum 历史命令的示例。

查看完整的 Yum 历史

要查看 Yum 事务完整的历史记录,我们可以运行以下命令,然后将显示:事务 ID、执行特定操作的用户、操作发生的日期和时间、实际操作以及任何错误的附加信息与操作:

# yum history 

查看 Yum 历史

使用 Yum 查找软件包信息

history 的子命令:info/list/summary 可以将事务 ID 或包名作为参数。此外,list 子命令可以加上特殊的参数,all 表示所有的事务。

运行以下命令查看先前的历史:

# yum history list all

并且,你可以使用下面的 info 命令查看涉及指定软件包的事务详情,例如 httpd

# yum history info httpd

Yum - 查找软件包信息

发出以下命令可以获得包含 httpd 软件包的事务的摘要:

# yum history summary httpd

Yum - 查找软件包的摘要

还可以使用事务的 ID 来查找,以下命令会显示 ID 为 15 的事务的详情。

# yum history info 15

Yum - 使用 ID 查找软件包信息

使用 yum history 查找软件包事务信息

有一些用于打印某个或多个软件包事务详情的子命令。我们可以使用 package-listpackage_info 查看关于 httpd 的更多信息,例如:

# yum history package-list httpd
或
# yum history package-info httpd

Yum - 查找软件包事务信息

要得到多个软件包的记录,我们可以运行:

# yum history package-list httpd epel-release
或
# yum history packages-list httpd epel-release

Yum - 查找多个软件包的信息

使用 Yum 回滚软件包

此外,还有一些 history 的子命令可以让我们撤销/重做/回滚事务。

  1. undo - 会撤销一个指定的事务。
  2. redo - 重复一次指定的事务。
  3. rollback - 撤销指定事务之后的所有事务。

它们采用单个事务 id 或关键字 last 和从最后一个事务开始的偏移量。

例如,假设我们已经做了 60 个事务,last 是指事务 60,last-4 指向事务 56。

推荐阅读: 怎样使用 yum-utils 来维护以及加速 Yum

以上子命令是如下工作的:如果我们有 5 个事务——V,W,X,Y 和 Z,其中分别是安装各个软件包的。

# yum history undo 2    #将删除软件包 W
# yum history redo 2    #将重新安装软件包 W
# yum history rollback 2    #将删除软件包 X、 Y 和 Z

在下面的示例中,事务 2 是一个更新操作,如下所示,以下 redo 命令将重复事务 2 直到所有软件包到更新到当前时间的最新版本:

# yum history | grep -w "2"

Yum - 查找软件包事务的 ID

# yum history redo 2

用 Yum 重新更新软件包

redo 子命令同样可以在我们指定事务之前加上一些可选的参数:

  1. force-reinstall - 重新安装所有在此事务中安装的软件包(通过 yum installupgradedowngrade)。
  2. force-remove - 移除所有已经更新或回滚的软件包。
# yum history redo force-reinstall 16

Yum - 强制安装软件包

查找 Yum 历史数据库和来源信息

这些子命令为我们提供有关历史记录数据库和其它信息来源的信息:

  1. addon-info - 提供更多的信息来源。
  2. stats - 显示当前历史数据库的统计信息。
  3. sync - 使我们能够更改为所有已安装软件包存储的 rpmdb/yumdb 数据。

看一下以下的命令的子命令实际上是怎样工作的:

# yum history addon-info
# yum history stats
# yum history sync

使用 new 子命令设置新的历史文件:

# yum history new

我们可以在 yum 手册页找到关于 Yum history 命令和其它几个命令的完整信息:

# man yum

推荐阅读: 4 个使用 Yum 禁用/锁定某些软件包更新的方法

就是这么多了。在本篇指南中,我们介绍了各种 Yum history 命令,以查看 Yum 事务的详细信息。


作者简介:

Aaron Kili 是 Linux 和 F.O.S.S 的爱好者,目前任 TecMint 的作者,志向是一名 Linux 系统管理员、web 开发者。他喜欢用电脑工作,并热衷于分享知识。


via: http://www.tecmint.com/view-yum-history-to-find-packages-info/

作者:Aaron Kili 译者:OneNewLife 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出