mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-01-28 23:20:10 +08:00
Merge remote-tracking branch 'LCTT/master'
This commit is contained in:
Xingyu.Wang
commit
ba2b940db9
@ -1,37 +1,43 @@
|
||||
迁徙到 Linux：命令行环境
|
||||
======
|
||||
|
||||
> 刚接触 Linux？在这篇教程中将学习如何轻松地在命令行列出、移动和编辑文件。
|
||||
|
||||
|
||||
|
||||
这是关于迁徙到 Linux 系列的第四篇文章了。如果您错过了之前的内容，可以回顾我们之前谈到的内容 [新手之 Linux][1]、[文件和文件系统][2]、和 [图形环境][3]。Linux 无处不在，它可以运行在大部分的网络服务器，如 web、email 和其他服务器；它同样可以在您的手机、汽车控制台和其他很多设备上使用。现在，您可能会开始好奇 Linux 系统，并对学习 Linux 的工作原理萌发兴趣。
|
||||
这是关于迁徙到 Linux 系列的第四篇文章了。如果您错过了之前的内容，可以回顾我们之前谈到的内容 [新手之 Linux][1]、[文件和文件系统][2]、和 [图形环境][3]。Linux 无处不在，它可以用于运行大部分的网络服务器，如 Web、email 和其他服务器；它同样可以在您的手机、汽车控制台和其他很多设备上使用。现在，您可能会开始好奇 Linux 系统，并对学习 Linux 的工作原理萌发兴趣。
|
||||
|
||||
在 Linux 下，命令行非常实用。Linux 的桌面系统中，尽管命令行只是可选操作，但是您依旧能看见很多朋友开着一个命令行窗口和其他应用窗口并肩作战。在运行 Linux 系统的网络服务器中，命令行通常是唯一能直接与操作系统交互的工具。因此，命令行是有必要了解的，至少应当涉猎一些基础命令。
|
||||
在 Linux 下，命令行非常实用。Linux 的桌面系统中，尽管命令行只是可选操作，但是您依旧能看见很多朋友开着一个命令行窗口和其他应用窗口并肩作战。在互联网服务器上和在设备中运行 Linux 时（LCTT 译注：指 IoT），命令行通常是唯一能直接与操作系统交互的工具。因此，命令行是有必要了解的，至少应当涉猎一些基础命令。
|
||||
|
||||
在命令行（通常称之为 Linux shell）中，所有操作都是通过键入命令完成。您可以执行查看文件列表、移动文件位置、显示文件内容、编辑文件内容等一系列操作，通过命令行，您甚至可以查看网页中的内容。
|
||||
|
||||
如果您在 Windows（CMD 或者 PowerShell） 上已经熟悉关于命令行的使用，您是否想跳转到了解 Windows 命令行的章节上去？先了阅读这些内容吧。
|
||||
如果您在 Windows（CMD 或者 PowerShell） 上已经熟悉关于命令行的使用，您是否想跳转到“Windows 命令行用户”的章节上去？先阅读这些内容吧。
|
||||
|
||||
### 导语
|
||||
### 导航
|
||||
|
||||
在命令行中，这里有一个当前工作目录（文件夹和目录是同义词，在 Linux 中它们通常都被称为目录）的概念。如果没有特别指定目录，许多命令的执行会在当前目录下生效。比如，键入 `ls` 列出文件目录，当前工作目录的文件将会被列举出来。看一个例子：
|
||||
|
||||
在命令行中，这里有一个当前工作目录（文件夹和目录是同义词，在 Linux 中它们通常都被称为目录）的概念。如果没有特别指定目录，许多命令的执行会在当前目录下生效。比如，键入 ls 列出文件目录，当前工作目录的文件将会被列举出来。看一个例子：
|
||||
```
|
||||
$ ls
|
||||
Desktop Documents Downloads Music Pictures README.txt Videos
|
||||
```
|
||||
|
||||
`ls Documents` 这条命令将会列出 `Documents` 目录下的文件：
|
||||
|
||||
```
|
||||
$ ls Documents
|
||||
report.txt todo.txt EmailHowTo.pdf
|
||||
```
|
||||
|
||||
通过 `pwd` 命令可以显示当前您的工作目录。比如：
|
||||
|
||||
```
|
||||
$ pwd
|
||||
/home/student
|
||||
```
|
||||
|
||||
您可以通过 `cd` 命令改变当前目录并切换到您想要抵达的目录。比如：
|
||||
|
||||
```
|
||||
$ pwd
|
||||
/home/student
|
||||
@ -40,11 +46,12 @@ $ pwd
|
||||
/home/student/Downloads
|
||||
```
|
||||
|
||||
路径中的目录由 `/`（左斜杠）字符分隔。路径中有一个隐含的层次关系，比如 `/home/student` 目录中，home 是顶层目录，而 student 是 home 的子目录。
|
||||
路径中的目录由 `/`（左斜杠）字符分隔。路径中有一个隐含的层次关系，比如 `/home/student` 目录中，home 是顶层目录，而 `student` 是 `home` 的子目录。
|
||||
|
||||
路径要么是绝对路径，要么是相对路径。绝对路径由一个 `/` 字符打头。
|
||||
|
||||
相对路径由 `.` 或者 `..` 开始。在一个路径中，一个 `.` 意味着当前目录，`..` 意味着当前目录的上级目录。比如，`ls ../Documents` 意味着在此寻找当前目录的上级名为 `Documets` 的目录：
|
||||
相对路径由 `.` 或者 `..` 开始。在一个路径中，一个 `.` 意味着当前目录，`..` 意味着当前目录的上级目录。比如，`ls ../Documents` 意味着在此寻找当前目录的上级名为 `Documents` 的目录：
|
||||
|
||||
```
|
||||
$ pwd
|
||||
/home/student
|
||||
@ -57,9 +64,10 @@ $ ls ../Documents
|
||||
report.txt todo.txt EmailHowTo.pdf
|
||||
```
|
||||
|
||||
当您第一次打开命令行窗口时，您当前的工作目录被设置为您的家目录，通常为 `/home/<您的登录名>`。家目录专用于登陆之后存储您的专属文件。
|
||||
当您第一次打开命令行窗口时，您当前的工作目录被设置为您的家目录，通常为 `/home/<您的登录名>`。家目录专用于登录之后存储您的专属文件。
|
||||
|
||||
环境变量 `$HOME` 会展开为您的家目录，比如：
|
||||
|
||||
设置环境变量 `$HOME` 到您的家目录，比如：
|
||||
```
|
||||
$ echo $HOME
|
||||
/home/student
|
||||
@ -67,59 +75,67 @@ $ echo $HOME
|
||||
|
||||
下表显示了用于目录导航和管理简单的文本文件的一些命令摘要。
|
||||
|
||||
|
||||
|
||||
|
||||
### 搜索
|
||||
|
||||
有时我们会遗忘文件的位置，或者忘记了我要寻找的文件名。Linux 命令行有几个命令可以帮助您搜索到文件。
|
||||
|
||||
第一个命令是 `find`。您可以使用 `find` 命令通过文件名或其他属性搜索文件和目录。举个例子，当您遗忘了 todo.txt 文件的位置，我们可以执行下面的代码：
|
||||
第一个命令是 `find`。您可以使用 `find` 命令通过文件名或其他属性搜索文件和目录。举个例子，当您遗忘了 `todo.txt` 文件的位置，我们可以执行下面的代码：
|
||||
|
||||
```
|
||||
$ find $HOME -name todo.txt
|
||||
/home/student/Documents/todo.txt
|
||||
```
|
||||
|
||||
`find` 程序有很多功能和选项。一个简单的例子：
|
||||
|
||||
```
|
||||
find <要寻找的目录> -name <文件名>
|
||||
```
|
||||
|
||||
如果这里有 `todo.txt` 文件且不止一个，它将向我们列出拥有这个名字的所有文件的所有所在位置。`find` 命令有很多便于搜索的选项比如类型（文件或是目录等等）、时间、大小和其他一些选项。更多内容您可以同通过:`man find` 获取关于如何使用 `find` 命令的帮助。
|
||||
如果这里有 `todo.txt` 文件且不止一个，它将向我们列出拥有这个名字的所有文件的所有所在位置。`find` 命令有很多便于搜索的选项比如类型（文件或是目录等等）、时间、大小和其他一些选项。更多内容您可以同通过 `man find` 获取关于如何使用 `find` 命令的帮助。
|
||||
|
||||
您还可以使用 `grep` 命令搜索文件的特定内容，比如：
|
||||
|
||||
您还可以使用 `grep` 命令搜索文件的特殊内容，比如：
|
||||
```
|
||||
grep "01/02/2018" todo.txt
|
||||
```
|
||||
|
||||
这将为您展示 `todo` 文件中 `01/02/2018` 所在行。
|
||||
|
||||
### 获取帮助
|
||||
|
||||
Linux 有很多命令，这里,我们没有办法一一列举。授人以鱼不如授人以渔，所以下一步我们将向您介绍帮助命令。
|
||||
Linux 有很多命令，这里，我们没有办法一一列举。授人以鱼不如授人以渔，所以下一步我们将向您介绍帮助命令。
|
||||
|
||||
`apropos` 命令可以帮助您查找需要使用的命令。也许您想要查找能够操作目录或是获得文件列表的所有命令，但是您不知道该运行哪个命令。您可以这样尝试：
|
||||
|
||||
`apropos` 命令可以帮助您查找需要使用的命令。也许您想要查找能够操作目录或是获得文件列表的所有命令，但是您并不希望让这些命令执行。您可以这样尝试：
|
||||
```
|
||||
apropos directory
|
||||
```
|
||||
|
||||
要在帮助文档中，得到一个于 `directiory` 关键字的相关命令列表，您可以这样操作：
|
||||
|
||||
```
|
||||
apropos "list open files"
|
||||
```
|
||||
|
||||
这将提供一个 `lsof` 命令给您，帮助您打开文件列表。
|
||||
这将提供一个 `lsof` 命令给您，帮助您列出打开文件的列表。
|
||||
|
||||
当您明确知道您要使用的命令，但是不确定应该使用什么选项完成预期工作，您可以使用 `man` 命令，它是 manual 的缩写。您可以这样使用：
|
||||
|
||||
当您明确您要使用的命令，但是不确定应该使用什么选项完成预期工作，您可以使用 man 命令，它是 manual 的缩写。您可以这样使用：
|
||||
```
|
||||
man ls
|
||||
```
|
||||
|
||||
您可以在自己的设备上尝试这个命令。它会提供给您关于使用这个命令的完整信息。
|
||||
|
||||
通常，很多命令都会有能够给 `help` 选项（比如说，`ls --help`），列出命令使用的提示。`man` 页面的内容通常太繁琐，`--help` 选项可能更适合快速浏览。
|
||||
通常，很多命令都能够接受 `help` 选项（比如说，`ls --help`），列出命令使用的提示。`man` 页面的内容通常太繁琐，`--help` 选项可能更适合快速浏览。
|
||||
|
||||
### 脚本
|
||||
|
||||
Linux 命令行中最贴心的功能是能够运行脚本文件，并且能重复运行。Linux 命令可以存储在文本文件中，您可以在文件的开头写入 `#!/bin/sh`，之后追加命令。之后，一旦文件被存储为可执行文件，您就可以像执行命令一样运行脚本文件，比如，
|
||||
Linux 命令行中最贴心的功能之一是能够运行脚本文件，并且能重复运行。Linux 命令可以存储在文本文件中，您可以在文件的开头写入 `#!/bin/sh`，后面的行是命令。之后，一旦文件被存储为可执行文件，您就可以像执行命令一样运行脚本文件，比如，
|
||||
|
||||
```
|
||||
--- contents of get_todays_todos.sh ---
|
||||
#!/bin/sh
|
||||
@ -127,44 +143,53 @@ todays_date=`date +"%m/%d/%y"`
|
||||
grep $todays_date $HOME/todos.txt
|
||||
```
|
||||
|
||||
在一个确定的工作中脚本可以帮助自动化重复执行命令。如果需要的话，脚本也可以很复杂，能够使用循环、判断语句等。限于篇幅，这里不细述，但是您可以在网上查询到相关信息。
|
||||
脚本可以以一套可重复的步骤自动化执行特定命令。如果需要的话，脚本也可以很复杂，能够使用循环、判断语句等。限于篇幅，这里不细述，但是您可以在网上查询到相关信息。
|
||||
|
||||
您是否已经熟悉了 Windows 命令行？
|
||||
### Windows 命令行用户
|
||||
|
||||
如果您对 Windows CMD 或者 PowerShell 程序很熟悉，在命令行输入命令应该是轻车熟路的。然而，它们之间有很多差异，如果您没有理解它们之间的差异可能会为之困扰。
|
||||
|
||||
首先，在 Linux 下的 PATH 环境于 Windows 不同。在 Windows 中，当前目录被认为是路径中的第一个文件夹，尽管该目录没有在环境变量中列出。而在 Linux 下，当前目录不会在路径中显示表示。Linux 下设置环境变量会被认为是风险操作。在 Linux 的当前目录执行程序，您需要使用 ./（代表当前目录的相对目录表示方式） 前缀。这可能会干扰很多 CMD 用户。比如：
|
||||
首先，在 Linux 下的 `PATH` 环境与 Windows 不同。在 Windows 中，当前目录被认为是该搜索路径（`PATH`）中的第一个文件夹，尽管该目录没有在环境变量中列出。而在 Linux 下，当前目录不会明确的放在搜索路径中。Linux 下设置环境变量会被认为是风险操作。在 Linux 的当前目录执行程序，您需要使用 `./`（代表当前目录的相对目录表示方式） 前缀。这可能会搞糊涂很多 CMD 用户。比如：
|
||||
|
||||
```
|
||||
./my_program
|
||||
```
|
||||
|
||||
而不是
|
||||
|
||||
```
|
||||
my_program
|
||||
```
|
||||
|
||||
另外，在 Windows 环境变量的路径中是以 `;`（分号） 分割的。在 Linux 中，由 `:` 分割环境变量。同样，在 Linux 中路径由 `/` 字符分隔，而在 Windows 目录中路径由 `\` 字符分割。因此 Windows 中典型的环境变量会像这样：
|
||||
|
||||
```
|
||||
PATH="C:\Program Files;C:\Program Files\Firefox;"
|
||||
while on Linux it might look like:
|
||||
```
|
||||
而在 Linux 中看起来像这样：
|
||||
|
||||
```
|
||||
PATH="/usr/bin:/opt/mozilla/firefox"
|
||||
```
|
||||
|
||||
还要注意，在 Linux 中环境变量由 `$` 拓展，而在 Windows 中您需要使用百分号（就是这样: %PATH%）。
|
||||
还要注意，在 Linux 中环境变量由 `$` 拓展，而在 Windows 中您需要使用百分号（就是这样： `%PATH%`）。
|
||||
|
||||
在 Linux 中，通过 `-` 使用命令选项，而在 Windows 中，使用选项要通过 `/` 字符。所以，在 Linux 中您应该：
|
||||
|
||||
```
|
||||
a_prog -h
|
||||
```
|
||||
|
||||
而不是
|
||||
|
||||
```
|
||||
a_prog /h
|
||||
```
|
||||
|
||||
在 Linux 下，文件拓展名并没有意义。例如，将 `myscript` 重命名为 `myscript.bat` 并不会因此而可执行，需要设置文件的执行权限。文件执行权限会在下次的内容中覆盖到。
|
||||
在 Linux 下，文件拓展名并没有意义。例如，将 `myscript` 重命名为 `myscript.bat` 并不会因此而变得可执行，需要设置文件的执行权限。文件执行权限会在下次的内容中覆盖到。
|
||||
|
||||
在 Linux 中，如果文件或者目录名以 `.` 字符开头，意味着它们是隐藏文件。比如，如果您申请编辑 `.bashrc` 文件，您不能在家目录中找到它，但是它可能真的存在，只不过它是隐藏文件。在命令行中，您可以通过 `ls` 命令的 `-a` 选项查看隐藏文件，比如：
|
||||
|
||||
在 Linux 中，如果文件或者目录名以 `.` 字符开头，意味着它们是隐藏文件。比如，如果您申请编辑 `.bashrc` 文件，您不能在 `home` 目录中找到它，但是它可能真的存在，只不过它是隐藏文件。在命令行中，您可以通过 `ls` 命令的 `-a` 选项查看隐藏文件，比如：
|
||||
```
|
||||
ls -a
|
||||
```
|
||||
@ -179,11 +204,11 @@ via: https://www.linux.com/blog/learn/2018/1/migrating-linux-command-line
|
||||
|
||||
作者：[John Bonesio][a]
|
||||
译者：[CYLeft](https://github.com/CYLeft)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://www.linux.com/users/johnbonesio
|
||||
[1]:https://www.linux.com/blog/learn/intro-to-linux/2017/10/migrating-linux-introduction
|
||||
[2]:https://www.linux.com/blog/learn/intro-to-linux/2017/11/migrating-linux-disks-files-and-filesystems
|
||||
[3]:https://www.linux.com/blog/learn/2017/12/migrating-linux-graphical-environments
|
||||
[1]:https://linux.cn/article-9212-1.html
|
||||
[2]:https://linux.cn/article-9213-1.html
|
||||
[3]:https://linux.cn/article-9293-1.html
|
||||
@ -1,8 +1,9 @@
|
||||
在 Fedora 中持续集成
|
||||
Fedora 社区的持续集成
|
||||
======
|
||||
|
||||
|
||||
持续集成 （CI） 是为项目的每一项变更运行测试的过程，如同这是新的交付项目一样。如果持续执行，这意味着软件随时可以发布。 CI 是整个 IT 行业以及免费和开源项目非常成熟的流程。Fedora 在这方面有点落后，但我们正在赶上。阅读以下内容了解进展。
|
||||
|
||||
<ruby>持续集成<rt>Continuous Integration</rt></ruby>（CI） 是为项目的每一项变更运行测试的过程，如同这是新的交付项目一样。如果持续执行，这意味着软件随时可以发布。 CI 是整个 IT 行业以及自由开源项目非常成熟的流程。Fedora 在这方面有点落后，但我们正在赶上。阅读以下内容了解进展。
|
||||
|
||||
### 我们为什么需要这个？
|
||||
|
||||
@ -12,7 +13,7 @@ CI 将全面改善 Fedora。它通过尽早揭示 bug 提供更稳定和一致
|
||||
|
||||
### 它看起来如何？
|
||||
|
||||
对于初学者，我们将对在 Fedora 包 （dist-git） 仓库的每个提交运行测试。这些测试独立于构建时运行的每个软件包的测试。但是，他们在尽可能接近 Fedora 用户运行环境的环境中测试软件包的功能。除了特定的软件包测试外，Fedora 还运行一些发行测试，例如从 F27 升级到 F28 或者全新安装。
|
||||
对于初学者，我们将对在 Fedora 包仓库 （dist-git） 的每个提交运行测试。这些测试独立于构建时运行的每个软件包的测试。但是，它们在尽可能接近 Fedora 用户运行环境的环境中测试软件包的功能。除了特定的软件包测试外，Fedora 还运行一些发行版测试，例如从 F27 升级到 F28 或者全新安装。
|
||||
|
||||
软件包根据测试结果进行“控制”：测试失败会阻止将更新推送给用户。但是，有时由于各种原因，测试会失败。也许测试本身是错误的，或者不是最新的软件。或者可能发生基础架构问题，并阻止测试正常运行。维护人员能够重新触发测试或放弃测试结果，直到测试更新。
|
||||
|
||||
@ -20,28 +21,25 @@ CI 将全面改善 Fedora。它通过尽早揭示 bug 提供更稳定和一致
|
||||
|
||||
### 我们如今有什么？
|
||||
|
||||
目前，CI 管道在 Fedora Atomic Host 一部分软件包上运行测试。其他软件包可以在 dist-git 中进行测试，但它们不会自动运行。分发特定的测试已经在我们所有的软件包上运行。这些测试结果被用于过滤测试失败的软件包。
|
||||
目前，CI 管道在 Fedora Atomic Host 的部分软件包上运行测试。其他软件包可以在 dist-git 中进行测试，但它们不会自动运行。发行版特定的测试已经在我们所有的软件包上运行。这些测试结果被用于过滤测试失败的软件包。
|
||||
|
||||
### 我该如何参与？
|
||||
|
||||
最好的入门方法是阅读关于[ Fedora 持续集成][1]的文档。你应该熟悉[标准测试接口][2]，它描述了很多术语以及如何编写测试和使用现有的测试。
|
||||
最好的入门方法是阅读关于 [Fedora 持续集成][1]的文档。你应该熟悉[标准测试接口][2]，它描述了很多术语以及如何编写测试和使用现有的测试。
|
||||
|
||||
有了这些知识，如果你是一个软件包维护者，你可以开始添加测试到你的软件包。你可以在本地或虚拟机上运行它们。 （后者对于破坏性测试是明治的！）
|
||||
有了这些知识，如果你是一个软件包维护者，你可以开始添加测试到你的软件包。你可以在本地或虚拟机上运行它们。 （对于破坏性测试来说后者是明智的！）
|
||||
|
||||
标准测试接口使测试保持一致。因此，你可以轻松地将任何测试添加到你喜欢的包中，并在 [仓库][3] 提交合并请求给维护人员。
|
||||
|
||||
Reach out on #fedora-ci on irc.freenode.net with feedback, questions or for a general discussion on CI.
|
||||
在 irc.freenode.net 上与 #fedora-ci 联系，提供反馈，问题或关于 CI 的一般性讨论。
|
||||
|
||||
[Samuel Zeller][4] 在 [Unsplash][5] 上提供的照片
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://fedoramagazine.org/continuous-integration-fedora/
|
||||
|
||||
作者：[Pierre-Yves Chibon;Dominik Perpeet][a]
|
||||
作者：[Pierre-Yves Chibon][a]
|
||||
译者：[geekpi](https://github.com/geekpi)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
157
published/20180407 12 Git tips for Git-s 12th birthday.md
Normal file
157
published/20180407 12 Git tips for Git-s 12th birthday.md
Normal file
@ -0,0 +1,157 @@
|
||||
13 个 Git 技巧献给 Git 13 岁生日
|
||||
=====
|
||||
|
||||
> 这 13 个 Git 技巧将使你的版本控制技能 +1、+1、+1……
|
||||
|
||||
|
||||
|
||||
[Git][1] 是一个分布式版本控制系统，它已经成为开源世界中源代码控制的默认工具，在 4 月 7 日这天，它 13 岁了。使用 Git 令人沮丧的事情之一是你需要知道更多才能有效地使用 Git。但这也可能是使用 Git 比较美妙的一件事，因为没有什么比发现一个新技巧来简化或提高你的工作流的效率更令人快乐了。
|
||||
|
||||
为了纪念 Git 的 13 岁生日，这里有 13 条技巧和诀窍来让你的 Git 经验更加有用和强大。从你可能忽略的一些基本知识开始，并扩展到一些真正的高级用户技巧！
|
||||
|
||||
### 1、 你的 ~/.gitconfig 文件
|
||||
|
||||
当你第一次尝试使用 `git` 命令向仓库提交一个更改时，你可能会收到这样的欢迎信息：
|
||||
|
||||
```
|
||||
*** Please tell me who you are.
|
||||
|
||||
Run
|
||||
|
||||
git config --global user.email "you@example.com"
|
||||
|
||||
git config --global user.name "Your Name"
|
||||
|
||||
to set your account's default identity.
|
||||
```
|
||||
|
||||
你可能没有意识到正是这些命令在修改 `~/.gitconfig` 的内容，这是 Git 存储全局配置选项的地方。你可以通过 `~/.gitconfig` 文件来做大量的事，包括定义别名、永久性打开（或关闭）特定命令选项，以及修改 Git 工作方式（例如，`git diff` 使用哪个 diff 算法，或者默认使用什么类型的合并策略）。你甚至可以根据仓库的路径有条件地包含其他配置文件！所有细节请参阅 `man git-config`。
|
||||
|
||||
### 2、 你仓库中的 .git/config 文件
|
||||
|
||||
在之前的技巧中，你可能想知道 `git config` 命令中 `--global` 标志是干什么的。它告诉 Git 更新 `~/.gitconfig` 中的“全局”配置。当然，有全局配置也意味着会有本地配置，显然，如果你省略 `--global` 标志，`git config` 将改为更新仓库特有的配置，该配置存储在 `.git/config` 中。
|
||||
|
||||
在 `.git/config` 文件中设置的选项将覆盖 `~/.gitconfig` 文件中的所有设置。因此，例如，如果你需要为特定仓库使用不同的电子邮件地址，则可以运行 `git config user.email "also_you@example.com"`。然后，该仓库中的任何提交都将使用你单独配置的电子邮件地址。如果你在开源项目中工作，而且希望它们显示自己的电子邮件地址，同时仍然使用自己工作邮箱作为主 Git 配置，这非常有用。
|
||||
|
||||
几乎任何你可以在 `~/.gitconfig` 中设置的东西，你也可以在 `.git/config` 中进行设置，以使其作用于特定的仓库。在下面的技巧中，当我提到将某些内容添加到 `~/.gitconfig` 时，只需记住你也可以在特定仓库的 `.git/config` 中添加来设置那个选项。
|
||||
|
||||
### 3、 别名
|
||||
|
||||
别名是你可以在 `~/.gitconfig` 中做的另一件事。它的工作原理就像命令行中的 shell —— 它们设定一个新的命令名称，可以调用一个或多个其他命令，通常使用一组特定的选项或标志。它们对于那些你经常使用的又长又复杂的命令来说非常有效。
|
||||
|
||||
你可以使用 `git config` 命令来定义别名 —— 例如，运行 `git config --global --add alias.st status` 将使运行 `git st` 与运行 `git status` 做同样的事情 —— 但是我在定义别名时发现，直接编辑 `~/.gitconfig` 文件通常更容易。
|
||||
|
||||
如果你选择使用这种方法，你会发现 `~/.gitconfig` 文件是一个 [INI 文件][2]。INI 是一种带有特定段落的键值对文件格式。当添加一个别名时，你将改变 `[alias]` 段落。例如，定义上面相同的 `git st` 别名时，添加如下到文件：
|
||||
|
||||
```
|
||||
[alias]
|
||||
st = status
|
||||
```
|
||||
|
||||
（如果已经有 `[alias]` 段落，只需将第二行添加到现有部分。）
|
||||
|
||||
### 4、 shell 命令中的别名
|
||||
|
||||
别名不仅仅限于运行其他 Git 子命令 —— 你还可以定义运行其他 shell 命令的别名。这是一个用来处理一个反复发生的、罕见和复杂的任务的很好方式：一旦你确定了如何完成它，就可以在别名下保存该命令。例如，我有一些<ruby>复刻<rt>fork</rt></ruby>的开源项目的仓库，并进行了一些本地修改。我想跟上项目正在进行的开发工作，并保存我本地的变化。为了实现这个目标，我需要定期将来自上游仓库的更改合并到我复刻的项目中 —— 我通过使用我称之为 `upstream-merge` 的别名来完成。它是这样定义的：
|
||||
|
||||
```
|
||||
upstream-merge = !"git fetch origin -v && git fetch upstream -v && git merge upstream/master && git push"
|
||||
```
|
||||
|
||||
别名定义开头的 `!` 告诉 Git 通过 shell 运行这个命令。这个例子涉及到运行一些 `git` 命令，但是以这种方式定义的别名可以运行任何 shell 命令。
|
||||
|
||||
（注意，如果你想复制我的 `upstream-merge` 别名，你需要确保你有一个名为 `upstream` 的 Git 远程仓库，指向你已经分配的上游仓库，你可以通过运行 `git remote add upstream <URL to repo>` 来添加一个。）
|
||||
|
||||
### 5、 可视化提交图
|
||||
|
||||
如果你在一个有很多分支活动的项目上开发，有时可能很难掌握所有正在发生的工作以及它们之间的相关性。各种图形用户界面工具可让你获取不同分支的图片并在所谓的“提交图表”中提交。例如，以下是我使用 [GitLab][3] 提交图表查看器可视化的我的一个仓库的一部分：
|
||||
|
||||
![GitLab commit graph viewer][5]
|
||||
|
||||
如果你是一个专注于命令行的用户或者发现分支切换工具让人分心，那么可以从命令行获得类似的提交视图。这就是 `git log` 命令的 `--graph` 参数出现的地方：
|
||||
|
||||
![Repository visualized with --graph command][7]
|
||||
|
||||
以下命令可视化相同仓库可达到相同效果：
|
||||
|
||||
```
|
||||
git log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative
|
||||
```
|
||||
|
||||
`--graph` 选项将图添加到日志的左侧，`--abbrev-commit` 缩短提交的 [SHA][8] 值，`--date=relative` 以相对方式表示日期，以及 `--pretty` 来处理所有其他自定义格式。我有个 `git lg` 别名用于这个功能，它是我最常用的 10 个命令之一。
|
||||
|
||||
### 6、 更优雅的强制推送
|
||||
|
||||
有时，你越是想避开越避不开，你会发现你需要运行 `git push --force` 来覆盖仓库远程副本上的历史记录。你可能得到了一些反馈，需要你进行交互式<ruby>变基<rt>rebase</rt></ruby>，或者你可能已经搞砸了，并希望隐藏“罪证”。
|
||||
|
||||
当其他人在仓库的远程副本的同一分支上进行更改时，会发生强制推送的危险。当你强制推送已重写的历史记录时，这些提交将会丢失。这就是 `git push --force-with-lease` 出现的原因 -- 如果远程分支已经更新，它不会允许你强制推送，这确保你不会丢掉别人的工作。
|
||||
|
||||
### 7、 git add -N
|
||||
|
||||
你是否使用过 `git commit -a` 在一次行动中提交所有未完成的修改，但在你推送完提交后才发现 `git commit -a` 忽略了新添加的文件？你可以使用 `git add -N` (想想 “notify”) 来解决这个问题，告诉 Git 在第一次实际提交它们之前，你希望在提交中包含新增文件。
|
||||
|
||||
### 8、 git add -p
|
||||
|
||||
使用 Git 时的最佳做法是确保每次提交都只包含一个逻辑修改 —— 无论这是修复错误还是添加新功能。然而，有时当你在工作时，你的仓库中的修改最终应该使用多个提交。你怎样才能设法把事情分开，使每个提交只包含适当的修改呢？`git add --patch` 来拯救你了！
|
||||
|
||||
这个标志会让 `git add` 命令查看你工作副本中的所有变化，并为每个变化询问你是否想要将它提交、跳过，或者推迟决定（你可以在运行该命令后选择 `?` 来查看其他更强大的选项）。`git add -p` 是生成结构良好的提交的绝佳工具。
|
||||
|
||||
### 9、 git checkout -p
|
||||
|
||||
与 `git add -p` 类似，`git checkout` 命令也接受 `--patch` 或 `-p` 选项，这会使其在本地工作副本中显示每个“大块”的改动，并允许丢弃它 —— 简单来说就是将本地工作副本恢复到更改之前的状态。
|
||||
|
||||
这真的很棒。例如，当你追踪一个 bug 时引入了一堆调试日志语句，修正了这个 bug 之后，你可以先使用 `git checkout -p` 移除所有新的调试日志，然后 `git add -p` 来添加 bug 修复。没有比组合一个优雅的、结构良好的提交更令人满意！
|
||||
|
||||
### 10、 变基时执行命令
|
||||
|
||||
有些项目有一个规则，即存储库中的每个提交都必须处于可工作状态 —— 也就是说，在每次提交时，应该可以编译该代码，或者应该运行测试套件而不会失败。 当你在分支上工作时，这并不困难，但是如果你最终因为某种原因需要<ruby>变基<rt>rebase</rt></ruby>时，那么需要逐步完成每个变基的提交以确保你没有意外地引入一个中断，而这个过程是乏味的。
|
||||
|
||||
幸运的是，`git rebase` 已经覆盖了 `-x` 或 `--exec` 选项。`git rebase -x <cmd>` 将在每个提交在变基中被应用后运行该命令。因此，举个例子，如果你有一个项目，其中使用 `npm run tests` 运行你的测试套件，`git rebase -x npm run tests` 将在变基期间每次提交之后运行测试套件。这使你可以查看测试套件是否在任何变基的提交中失败，以便你可以确认测试套件在每次提交时仍能通过。
|
||||
|
||||
### 11、 基于时间的修订引用
|
||||
|
||||
很多 Git 子命令都接受一个修订参数来决定命令作用于仓库的哪个部分，可以是某次特定的提交的 SHA1 值，一个分支的名称，甚至是一个符号性的名称如 `HEAD`（代表当前检出分支最后一次的提交），除了这些简单的形式以外，你还可以附加一个指定的日期或时间作为参数，表示“这个时间的引用”。
|
||||
|
||||
这个功能在某些时候会变得十分有用。当你处理最新出现的 bug，自言自语道：“这个功能昨天还是好好的，到底又改了些什么”，不用盯着满屏的 `git log` 的输出试图弄清楚什么时候更改了提交，你只需运行 `git diff HEAD@{yesterday}`，看看从昨天以来的所有修改。这也适用于更长的时间段（例如 `git diff HEAD@{'2 months ago'}`），以及一个确切的日期（例如 `git diff HEAD@{'2010-01-01 12:00:00'}`）。
|
||||
|
||||
你也可以将这些基于日期的修订参数与使用修订参数的任何 Git 子命令一起使用。在 `gitrevisions` 手册页中有关于具体使用哪种格式的详细信息。
|
||||
|
||||
### 12、 全知的 reflog
|
||||
|
||||
你是不是试过在变基时干掉过某次提交，然后发现你需要保留那个提交中一些东西？你可能觉得这些信息已经永远找不回来了，只能重新创建。但是如果你在本地工作副本中提交了，提交就会被添加到引用日志（reflog）中 ，你仍然可以访问到。
|
||||
|
||||
运行 `git reflog` 将在本地工作副本中显示当前分支的所有活动的列表，并为你提供每个提交的 SHA1 值。一旦发现你变基时放弃的那个提交，你可以运行 `git checkout <SHA1>` 跳转到该提交，复制任何你需要的信息，然后再运行 `git checkout HEAD` 返回到分支最近的提交去。
|
||||
|
||||
### 13、自己清理
|
||||
|
||||
哎呦！ 事实证明，我的基本数学技能不如我的 Git 技能。 Git 最初是在 2005 年发布的，这意味着它今年会变成 13 岁，而不是 12 岁（LCTT 译注：本文原来是以 12 岁生日为题的）。为了弥补这个错误，这里有可以让我们变成十三岁的第 13 条技巧。
|
||||
|
||||
如果你使用基于分支的工作流，随着在一个长期项目上的工作，除非你在每个分支合并时清理干净，否则你最终会得到一大堆分支。这使得你难于找到想要的分支，分支的森林会让你无从找起。甚至更糟糕的是，如果你有大量活跃的分支，确定一个分支是否被合并（可以被安全删除）或仍然没有被合并而应该留下会非常繁琐。幸运的是，Git 可以帮到你：只需要运行 `git branch --merged` 就可以得到已经被合并到你的当前分支的分支列表，或者 `git branch --no-merged` 找出被合并到其它分支的分支。默认情况下这会列出你本地工作副本的分支，但是如果你在命令行包括 `--remote` 或 `-r` 参数，它也会列出仅存于远程仓库的已合并分支。
|
||||
|
||||
重要提示：如果你计划使用 `git branch --merged` 的输出来清理那些已合并的分支，你要小心它的输出也包括了当前分支（毕竟，这个当前的分支就被合并到当前分支！）。确保你在任何销毁动作之前排除了该分支（如果你忘记了，参见第 12 条技巧来学习 reflog 怎样帮你把分支找回来，希望有用……）。
|
||||
|
||||
### 以上是全部内容
|
||||
|
||||
希望这些技巧中至少有一个能够教给你一些关于 Git 的新东西，Git 是一个有 13 年历史的项目，并且在持续创新和增加新功能中。你最喜欢的 Git 技巧是什么？
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/18/4/git-tips
|
||||
|
||||
作者：[John SJ Anderson][a]
|
||||
选题：[lujun9972](https://github.com/lujun9972)
|
||||
译者：[MjSeven](https://github.com/MjSeven)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://opensource.com/users/genehack
|
||||
[1]:https://git-scm.com/
|
||||
[2]:https://en.wikipedia.org/wiki/INI_file
|
||||
[3]:https://gitlab.com/
|
||||
[4]:/file/392941
|
||||
[5]:https://opensource.com/sites/default/files/styles/panopoly_image_original/public/u128651/gui_graph.png?itok=3GovYfG1 (GitLab commit graph viewer)
|
||||
[6]:/file/392936
|
||||
[7]:https://opensource.com/sites/default/files/styles/panopoly_image_original/public/u128651/console_graph.png?itok=XogY1P8M (Repository visualized with --graph command)
|
||||
[8]:https://en.wikipedia.org/wiki/Secure_Hash_Algorithms
|
||||
@ -1,117 +0,0 @@
|
||||
pinewall translating
|
||||
|
||||
Containers without Docker at Red Hat
|
||||
======
|
||||
|
||||
The Docker (now [Moby][1]) project has done a lot to popularize containers in recent years. Along the way, though, it has generated concerns about its concentration of functionality into a single, monolithic system under the control of a single daemon running with root privileges: `dockerd`. Those concerns were reflected in a [talk][2] by Dan Walsh, head of the container team at Red Hat, at [KubeCon \+ CloudNativeCon][3]. Walsh spoke about the work the container team is doing to replace Docker with a set of smaller, interoperable components. His rallying cry is "no big fat daemons" as he finds them to be contrary to the venerated Unix philosophy.
|
||||
|
||||
### The quest to modularize Docker
|
||||
|
||||
As we saw in an [earlier article][4], the basic set of container operations is not that complicated: you need to pull a container image, create a container from the image, and start it. On top of that, you need to be able to build images and push them to a registry. Most people still use Docker for all of those steps but, as it turns out, Docker isn't the only name in town anymore: an early alternative was `rkt`, which led to the creation of various standards like CRI (runtime), OCI (image), and CNI (networking) that allow backends like [CRI-O][5] or Docker to interoperate with, for example, [Kubernetes][6].
|
||||
|
||||
These standards led Red Hat to create a set of "core utils" like the CRI-O runtime that implements the parts of the standards that Kubernetes needs. But Red Hat's [OpenShift][7] project needs more than what Kubernetes provides. Developers will want to be able to build containers and push them to the registry. Those operations need a whole different bag of tricks.
|
||||
|
||||
It turns out that there are multiple tools to build containers right now. Apart from Docker itself, a [session][8] from Michael Ducy of Sysdig reviewed eight image builders, and that's probably not all of them. Ducy identified the ideal build tool as one that would create a minimal image in a reproducible way. A minimal image is one where there is no operating system, only the application and its essential dependencies. Ducy identified [Distroless][9], [Smith][10], and [Source-to-Image][11] as good tools to build minimal images, which he called "micro-containers".
|
||||
|
||||
A reproducible container is one that you can build multiple times and always get the same result. For that, Ducy said you have to use a "declarative" approach (as opposed to "imperative"), which is understandable given that he comes from the Chef configuration-management world. He gave the examples of [Ansible Container][12], [Habitat][13], [nixos-container][14], and Smith (yes, again) as being good approaches, provided you were familiar with their domain-specific languages. He added that Habitat ships its own supervisor in its containers, which may be superfluous if you already have an external one, like systemd, Docker, or Kubernetes. To complete the list, we should mention the new [BuildKit][15] from Docker and [Buildah][16], which is part of Red Hat's [Project Atomic][17].
|
||||
|
||||
### Building containers with Buildah
|
||||
|
||||
![\[Buildah logo\]][18] Buildah's name apparently comes from Walsh's colorful [Boston accent][19]; the Boston theme permeates the branding of the tool: the logo, for example, is a Boston terrier dog (seen at right). This project takes a different approach from Ducy's decree: instead of enforcing a declarative configuration-management approach to containers, why not build simple tools that can be used by your favorite configuration-management tool? If you want to use regular command-line commands like `cp` (instead of Docker's custom `COPY` directive, for example), you can. But you can also use Ansible or Puppet, OS-specific or language-specific installers like APT or pip, or whatever other system to provision the content of your containers. This is what building a container looks like with regular shell commands and simply using `make` to install a binary inside the container:
|
||||
```
|
||||
# pull a base image, equivalent to a Dockerfile's FROM command
|
||||
buildah from redhat
|
||||
|
||||
# mount the base image to work on it
|
||||
crt=$(buildah mount)
|
||||
cp foo $crt
|
||||
make install DESTDIR=$crt
|
||||
|
||||
# then make a snapshot
|
||||
buildah commit
|
||||
|
||||
```
|
||||
|
||||
An interesting thing with this approach is that, since you reuse normal build tools from the host environment, you can build really minimal images because you don't need to install all the dependencies in the image. Usually, when building a container image, the target application build dependencies need to be installed within the container. For example, building from source usually requires a compiler toolchain in the container, because it is not meant to access the host environment. A lot of containers will also ship basic Unix tools like `ps` or `bash` which are not actually necessary in a micro-container. Developers often forget to (or simply can't) remove some dependencies from the built containers; that common practice creates unnecessary overhead and attack surface.
|
||||
|
||||
The modular approach of Buildah means you can run at least parts of the build as non-root: the `mount` command still needs the `CAP_SYS_ADMIN` capability, but there is an [issue][20] open to resolve this. However, Buildah [shares][21] the same [limitation][22] as Docker in that it can't build containers inside containers. For Docker, you need to run the container in "privileged" mode, which is not possible in certain environments (like [GitLab Continuous Integration][23], for example) and, even when it is possible, the configuration is [messy][24] at best.
|
||||
|
||||
The manual commit step allows fine-grained control over when to create container snapshots. While in a Dockerfile every line creates a new snapshot, with Buildah commit checkpoints are explicitly chosen, which reduces unnecessary snapshots and saves disk space. This is useful to isolate sensitive material like private keys or passwords which sometimes mistakenly end up in public images as well.
|
||||
|
||||
While Docker builds non-standard, Docker-specific images, Buildah produces standard OCI images among [other output formats][25]. For backward compatibility, it has a command called `build-using-dockerfile` or [`buildah bud`][26] that parses normal Dockerfiles. Buildah has a `enter` command to inspect images from the inside directly and a `run` command to start containers on the fly. It does all the work without any "fat daemon" running in the background and uses standard tools like `runc`.
|
||||
|
||||
Ducy's criticism of Buildah was that it was not declarative, which made it less reproducible. When allowing shell commands anything can happen: for example, a shell script might download arbitrary binaries, without any way of subsequently retracing where those come from. Shell command effects may vary according to the environment. In contrast to shell-based tools, configuration-management systems like Puppet or Chef are designed to "converge" over a final configuration that is more reliable, at least in theory: in practice you can call shell commands from configuration-management systems. Walsh, however, argued that existing configuration management can be used on top of Buildah, but it doesn't force users down that path. This fits well with the classic "separation" principle of the Unix philosophy ("mechanism not policy").
|
||||
|
||||
At this point, Buildah is in beta and Red Hat is working on integrating it into OpenShift. I have tested Buildah while writing this article and, short of some documentation issues, it generally works reliably. It could use some polishing in error handling, but it is definitely a great asset to add to your container toolbox.
|
||||
|
||||
### Replacing the rest of the Docker command-line
|
||||
|
||||
Walsh continued his presentation by giving an overview of another project that Red Hat is working on, tentatively called [libpod][27]. The name derives from a "pod" in Kubernetes, which is a way to group containers inside a host, to share namespaces, for example.
|
||||
|
||||
Libpod includes the `kpod` command to inspect and manipulate container storage directly. Walsh explained this can be useful if, for example, `dockerd` hangs or if a Kubernetes cluster crashes. `kpod` is basically an independent re-implementation of the `docker` command-line tool. There is a command to list running containers (`kpod ps`) or images (`kpod images`). In fact, there is a [translation cheat sheet][28] documenting all Docker commands with a `kpod` equivalent.
|
||||
|
||||
One of the nice things with the modular approach is that when you run a container with `kpod run`, the container is directly started as a subprocess of the current shell, instead of a subprocess of `dockerd`. In theory, this allows running containers directly from systemd, removing the duplicate work `dockerd` is doing. It enables things like [socket-activated containers][29], which is something that is [not straightforward][30] to do with Docker, or [even with Kubernetes][31] right now. In my experiments, however, I have found that containers started with `kpod` lack some fundamental functionality, namely networking (!), although there is an [issue in progress][32] to complete that implementation.
|
||||
|
||||
A final command we haven't covered is `push`. While the above commands provide a good process for working with local containers, they don't cover remote registries, which allow developers to actively collaborate on application packaging. Registries are also an essential part of a continuous-deployment framework. This is where the [skopeo][33] project comes in. Skopeo is another Atomic project that "performs various operations on container images and image repositories", according to the `README` file. It was originally designed to inspect the contents of container registries without actually downloading the sometimes voluminous images as `docker pull` does. Docker [refused patches][34] to support inspection, suggesting the creation of a separate tool, which led to Skopeo. After `pull`, `push` was the logical next step and Skopeo can now do a bunch of other things like copying and converting images between registries without having to store a copy locally. Because this functionality was useful to other projects as well, a lot of the Skopeo code now lives in a reusable library called [containers/image][35]. That library is in turn used by [Pivotal][36], Google's [container-diff][37], `kpod push`, and `buildah push`.
|
||||
|
||||
`kpod` is not directly tied to Kubernetes, so the name might change in the future -- especially since Red Hat legal has not cleared the name yet. (In fact, just as this article was going to "press", the name was changed to [`podman`][38].) The team wants to implement more "pod-level" commands which would allow operations on multiple containers, a bit like what [`docker compose`][39] might do. But at that level, a better tool might be [Kompose][40] which can execute [Compose YAML files][41] into a Kubernetes cluster. Some Docker commands (like [`swarm`][42]) will never be implemented, on purpose, as they are best left for Kubernetes itself to handle.
|
||||
|
||||
It seems that the effort to modularize Docker that started a few years ago is finally bearing fruit. While, at this point, `kpod` is under heavy development and probably should not be used in production, the design of those different tools is certainly interesting; a lot of it is ready for development environments. Right now, the only way to install libpod is to compile it from source, but we should expect packages coming out for your favorite distribution eventually.
|
||||
|
||||
> This article [first appeared][43] in the [Linux Weekly News][44].
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://anarc.at/blog/2017-12-20-docker-without-docker/
|
||||
|
||||
作者：[À propos de moi][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://anarc.at
|
||||
[1]:https://mobyproject.org/
|
||||
[2]:https://kccncna17.sched.com/event/CU8j/cri-o-hosted-by-daniel-walsh-red-hat
|
||||
[3]:http://events.linuxfoundation.org/events/kubecon-and-cloudnativecon-north-america
|
||||
[4]:https://lwn.net/Articles/741897/
|
||||
[5]:http://cri-o.io/
|
||||
[6]:https://kubernetes.io/
|
||||
[7]:https://www.openshift.com/
|
||||
[8]:https://kccncna17.sched.com/event/CU6B/building-better-containers-a-survey-of-container-build-tools-i-michael-ducy-chef
|
||||
[9]:https://github.com/GoogleCloudPlatform/distroless
|
||||
[10]:https://github.com/oracle/smith
|
||||
[11]:https://github.com/openshift/source-to-image
|
||||
[12]:https://www.ansible.com/ansible-container
|
||||
[13]:https://www.habitat.sh/
|
||||
[14]:https://nixos.org/nixos/manual/#ch-containers
|
||||
[15]:https://github.com/moby/buildkit
|
||||
[16]:https://github.com/projectatomic/buildah
|
||||
[17]:https://www.projectatomic.io/
|
||||
[18]:https://raw.githubusercontent.com/projectatomic/buildah/master/logos/buildah-logomark_large.png (Buildah logo)
|
||||
[19]:https://en.wikipedia.org/wiki/Boston_accent
|
||||
[20]:https://github.com/projectatomic/buildah/issues/171
|
||||
[21]:https://github.com/projectatomic/buildah/issues/158
|
||||
[22]:https://github.com/moby/moby/issues/27886#issuecomment-281278525
|
||||
[23]:https://about.gitlab.com/features/gitlab-ci-cd/
|
||||
[24]:https://jpetazzo.github.io/2015/09/03/do-not-use-docker-in-docker-for-ci/
|
||||
[25]:https://github.com/projectatomic/buildah/blob/master/docs/buildah-push.md
|
||||
[26]:https://github.com/projectatomic/buildah/blob/master/docs/buildah-bud.md
|
||||
[27]:https://github.com/projectatomic/libpod
|
||||
[28]:https://github.com/projectatomic/libpod/blob/master/transfer.md#development-transfer
|
||||
[29]:http://0pointer.de/blog/projects/socket-activated-containers.html
|
||||
[30]:https://legacy-developer.atlassian.com/blog/2015/03/docker-systemd-socket-activation/
|
||||
[31]:https://github.com/kubernetes/kubernetes/issues/484
|
||||
[32]:https://github.com/projectatomic/libpod/issues/129
|
||||
[33]:https://github.com/projectatomic/skopeo
|
||||
[34]:https://github.com/moby/moby/pull/14258
|
||||
[35]:https://github.com/containers/image
|
||||
[36]:https://pivotal.io/
|
||||
[37]:https://github.com/GoogleCloudPlatform/container-diff
|
||||
[38]:https://github.com/projectatomic/libpod/blob/master/docs/podman.1.md
|
||||
[39]:https://docs.docker.com/compose/overview/#compose-documentation
|
||||
[40]:http://kompose.io/
|
||||
[41]:https://docs.docker.com/compose/compose-file/
|
||||
[42]:https://docs.docker.com/engine/swarm/
|
||||
[43]:https://lwn.net/Articles/741841/
|
||||
[44]:http://lwn.net/
|
||||
@ -1,3 +1,6 @@
|
||||
Translating by MjSeven
|
||||
|
||||
|
||||
Working with calendars on Linux
|
||||
======
|
||||
|
||||
|
||||
@ -1,168 +0,0 @@
|
||||
translating---geekpi
|
||||
|
||||
The Shuf Command Tutorial With Examples For Beginners
|
||||
======
|
||||
|
||||
|
||||
The Shuf command is used to generate random permutations in Unix-like operating systems. Using shuf command, we can shuffle the lines of a given input file randomly. Shuf command is part of GNU Coreutils, so you don’t have bother with installation. In this brief tutorial, let me show you some examples of shuf command.
|
||||
|
||||
### The Shuf Command Tutorial With Examples
|
||||
|
||||
I have a file named **ostechnix.txt** with the following contents.
|
||||
```
|
||||
$ cat ostechnix.txt
|
||||
line1
|
||||
line2
|
||||
line3
|
||||
line4
|
||||
line5
|
||||
line6
|
||||
line7
|
||||
line8
|
||||
line9
|
||||
line10
|
||||
|
||||
```
|
||||
|
||||
Now let us display the above lines in a random order. To do so, run:
|
||||
```
|
||||
$ shuf ostechnix.txt
|
||||
line2
|
||||
line8
|
||||
line5
|
||||
line10
|
||||
line7
|
||||
line1
|
||||
line4
|
||||
line6
|
||||
line9
|
||||
line3
|
||||
|
||||
```
|
||||
|
||||
See? The above command randomized the order of lines in the file named “ostechnix.txt” and output the result.
|
||||
|
||||
You might want to write the output to another file. For example, I want to save the output in a file named **output.txt**. To do so, first create output.txt file:
|
||||
```
|
||||
$ touch output.txt
|
||||
|
||||
```
|
||||
|
||||
Then, write the output to that file using **-o** flag like below.
|
||||
```
|
||||
$ shuf ostechnix.txt -o output.txt
|
||||
|
||||
```
|
||||
|
||||
The above command will shuffle the contents of ostechnix.txt file randomly and write the output to output.txt file. You can view the output.txt file contents using command:
|
||||
```
|
||||
$ cat output.txt
|
||||
|
||||
line2
|
||||
line8
|
||||
line9
|
||||
line10
|
||||
line1
|
||||
line3
|
||||
line7
|
||||
line6
|
||||
line4
|
||||
line5
|
||||
|
||||
```
|
||||
|
||||
I just want to display any one of the random line from the file. How do I do it? Simple!
|
||||
```
|
||||
$ shuf -n 1 ostechnix.txt
|
||||
line6
|
||||
|
||||
```
|
||||
|
||||
Similarly, we can pick the first “n” random entries. The following command will display the only the first five random entries.
|
||||
```
|
||||
$ shuf -n 5 ostechnix.txt
|
||||
line10
|
||||
line4
|
||||
line5
|
||||
line9
|
||||
line3
|
||||
|
||||
```
|
||||
|
||||
Instead of reading the lines from a file, we can directly pass the inputs using **-e** flag like below.
|
||||
```
|
||||
$ shuf -e line1 line2 line3 line4 line5
|
||||
line1
|
||||
line3
|
||||
line5
|
||||
line4
|
||||
line2
|
||||
|
||||
```
|
||||
|
||||
You can pass shuffle the numbers too:
|
||||
```
|
||||
$ shuf -e 1 2 3 4 5
|
||||
3
|
||||
5
|
||||
1
|
||||
4
|
||||
2
|
||||
|
||||
```
|
||||
|
||||
To quickly pick any one from the given range, use this command instead.
|
||||
```
|
||||
$ shuf -n 1 -e 1 2 3 4 5
|
||||
|
||||
```
|
||||
|
||||
Or, pick any three random numbers like below.
|
||||
```
|
||||
$ shuf -n 3 -e 1 2 3 4 5
|
||||
3
|
||||
5
|
||||
1
|
||||
|
||||
```
|
||||
|
||||
We can also generate random numbers within a particular range. For example, to display random numbers between 1 to 10, simply use:
|
||||
```
|
||||
$ shuf -i 1-10
|
||||
1
|
||||
9
|
||||
8
|
||||
2
|
||||
4
|
||||
7
|
||||
6
|
||||
3
|
||||
10
|
||||
5
|
||||
|
||||
```
|
||||
|
||||
For more details, refer man pages.
|
||||
```
|
||||
$ man shuf
|
||||
|
||||
```
|
||||
|
||||
And, that’s all for today. More good stuffs to come. Stay tuned!
|
||||
|
||||
Cheers!
|
||||
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.ostechnix.com/the-shuf-command-tutorial-with-examples-for-beginners/
|
||||
|
||||
作者：[SK][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
选题：[lujun9972](https://github.com/lujun9972)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://www.ostechnix.com/author/sk/
|
||||
@ -1,3 +1,5 @@
|
||||
translating---geekpi
|
||||
|
||||
Yet Another TUI Graphical Activity Monitor, Written In Go
|
||||
======
|
||||
|
||||
|
||||
@ -1,127 +0,0 @@
|
||||
translated by hopefully2333
|
||||
|
||||
Awesome GNOME extensions for developers
|
||||
======
|
||||
|
||||
|
||||
Extensions add immense flexibility to the GNOME 3 desktop environment. They give users the advantage of customizing their desktop while adding ease and efficiency to their workflow. The Fedora Magazine has already covered some great desktop extensions such as [EasyScreenCast][1], [gTile][2], and [OpenWeather][3]. This article continues that coverage by focusing on extensions tailored for developers.
|
||||
|
||||
If you need assistance installing GNOME extensions, refer to the article [How to install a GNOME Shell extension][4].
|
||||
|
||||
### ![Docker Integration extension icon][5] Docker Integration
|
||||
|
||||
![Docker Integration extension status menu][6]
|
||||
|
||||
The [Docker Integration][7] extension is a must for developers using Docker for their apps. The status menu provides a list of Docker containers with the option to start, stop, pause and even remove them. The list updates automatically as new containers are added to the system.
|
||||
|
||||
After installing this extension, Fedora users may get the message: “Error occurred when fetching containers.” This is because Docker commands require sudo or root permissions by default. To configure your user account to run Docker, refer to the [Docker Installation page on the Fedora Developer Portal][8].
|
||||
|
||||
You can find more information on the [extension’s website][9].
|
||||
|
||||
### ![Jenkins CI Server Indicator icon][10] Jenkins CI Server Indicator
|
||||
|
||||
![Jenkins CI Server Indicator extension status menu][11]
|
||||
|
||||
The [Jenkins CI Server Indicator][12] extension makes it easy for developers to build their apps on a Jenkins CI Server. It displays a menu with a list of jobs and the state of those jobs. It also includes features such as easy access to the Jenkins web front-end, notifications for completed jobs, and the ability to trigger and filter jobs.
|
||||
|
||||
For more information, visit the [developer’s site][13].
|
||||
|
||||
### ![android-tool extension icon][14] android-tool
|
||||
|
||||
![android-tool extension status menu][15][android-tool][16] can be a valuable extension for Android developers. Features include capturing bug reports, device screenshots and screen-recording. It can also connect to the Android device via USB or TCP.
|
||||
|
||||
This extension does require the adb package. To install adb from the official Fedora repository [run this command][17]:
|
||||
```
|
||||
sudo dnf install android-tools
|
||||
|
||||
```
|
||||
|
||||
You can find more information at [the extension Github site][18].
|
||||
|
||||
### ![GnomeHub extension icon][19] GnomeHub
|
||||
|
||||
![GnomeHub extension status menu][20][GnomeHub][21] is a great extension for GNOME users using Github for their projects. It displays Github repositories and notifies the user of opened pull requests. In addition, users can add their favorite repositories in the extension’s settings.
|
||||
|
||||
For more information, refer to [the project’s Github page][22].
|
||||
|
||||
### ![gistnotes extension icon][23] gistnotes
|
||||
|
||||
Quite simply, [gistnotes][24] provides easy access for gist users to create, store and manage notes or code snippets. For more information refer to [the project’s website][25].
|
||||
|
||||
![gistnotes window][26]
|
||||
|
||||
### ![Arduino Control extension icon][27] Arduino Control
|
||||
|
||||
The [Arduino Control][28] extension allows users to connect to, and control, their Arduino boards. It also lets users add sliders and switches in the status menu. In addition, the developer includes scripts in the extension’s directory to connect to the board via Ethernet or USB.
|
||||
|
||||
Most importantly, this extension can be customized to fit your project. An example provided in the README file is the ability to “Control your Room Lights from any Computer on the Network.”
|
||||
|
||||
You can read more about the features and setup of this extension on [the project’s Github page][29].
|
||||
|
||||
### ![Hotel Manager extension icon][30] Hotel Manager
|
||||
|
||||
![Hotel Manager extension status menu.][31]
|
||||
|
||||
Developers using the Hotel process manager for their web apps should explore the [Hotel Manager][32] extension. It displays a list of web apps added to Hotel, and gives users the ability to start, stop and restart those apps. Furthermore, the computers icon to the right gives quick access to open, or view, that web app. The extension can also start, stop, or restart the Hotel daemon.
|
||||
|
||||
As of the publication of this article, Hotel Manager version 4 for GNOME 3.26 does not list the web apps in the extension’s drop-down menu. Version 4 also gives errors when installing on Fedora 28 (GNOME 3.28). However, version 3 works with Fedora 27 and Fedora 28.
|
||||
|
||||
For more details, see [the project’s Github page][33].
|
||||
|
||||
### VSCode Search Provider
|
||||
|
||||
[VSCode Search Provider][34] is a simple extension that displays Visual Studio Code projects in the GNOME overview search results. For heavy VSCode users, this extension saves time by giving developers quick access to their projects. You can find more information on [the project’s Github page][35].
|
||||
|
||||
![GNOME Overview search results showing VSCode projects.][36]
|
||||
|
||||
Do you have a favourite extension you use for development? Let us know in the comments.
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://fedoramagazine.org/awesome-gnome-extensions-developers/
|
||||
|
||||
作者：[Shaun Assam][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
选题：[lujun9972](https://github.com/lujun9972)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://fedoramagazine.org/author/sassam/
|
||||
[1]:https://fedoramagazine.org/screencast-gnome-extension/
|
||||
[2]:https://fedoramagazine.org/must-have-gnome-extension-gtile/
|
||||
[3]:https://fedoramagazine.org/weather-updates-openweather-gnome-shell-extension/
|
||||
[4]:https://fedoramagazine.org/install-gnome-shell-extension/
|
||||
[5]:https://fedoramagazine.org/wp-content/uploads/2017/08/dockericon.png
|
||||
[6]:https://fedoramagazine.org/wp-content/uploads/2017/08/docker-extension-menu.png
|
||||
[7]:https://extensions.gnome.org/extension/1065/docker-status/
|
||||
[8]:https://developer.fedoraproject.org/tools/docker/docker-installation.html
|
||||
[9]:https://github.com/gpouilloux/gnome-shell-extension-docker
|
||||
[10]:https://fedoramagazine.org/wp-content/uploads/2017/08/jenkinsicon.png
|
||||
[11]:https://fedoramagazine.org/wp-content/uploads/2017/08/jenkins-extension-menu.png
|
||||
[12]:https://extensions.gnome.org/extension/399/jenkins-ci-server-indicator/
|
||||
[13]:https://www.philipphoffmann.de/gnome-3-shell-extension-jenkins-ci-server-indicator/
|
||||
[14]:https://fedoramagazine.org/wp-content/uploads/2017/08/androidtoolicon.png
|
||||
[15]:https://fedoramagazine.org/wp-content/uploads/2017/08/android-tool-extension-menu.png
|
||||
[16]:https://extensions.gnome.org/extension/1232/android-tool/
|
||||
[17]:https://fedoramagazine.org/howto-use-sudo/
|
||||
[18]:https://github.com/naman14/gnome-android-tool
|
||||
[19]:https://fedoramagazine.org/wp-content/uploads/2017/08/gnomehubicon.png
|
||||
[20]:https://fedoramagazine.org/wp-content/uploads/2017/08/gnomehub-extension-menu.png
|
||||
[21]:https://extensions.gnome.org/extension/1263/gnomehub/
|
||||
[22]:https://github.com/lagartoflojo/gnomehub
|
||||
[23]:https://fedoramagazine.org/wp-content/uploads/2017/08/gistnotesicon.png
|
||||
[24]:https://extensions.gnome.org/extension/917/gistnotes/
|
||||
[25]:https://github.com/mohan43u/gistnotes
|
||||
[26]:https://fedoramagazine.org/wp-content/uploads/2018/04/gistnoteswindow.png
|
||||
[27]:https://fedoramagazine.org/wp-content/uploads/2017/08/arduinoicon.png
|
||||
[28]:https://extensions.gnome.org/extension/894/arduino-control/
|
||||
[29]:https://github.com/simonthechipmunk/arduinocontrol
|
||||
[30]:https://fedoramagazine.org/wp-content/uploads/2017/08/hotelicon.png
|
||||
[31]:https://fedoramagazine.org/wp-content/uploads/2017/08/hotelmanager-extension-menu.png
|
||||
[32]:https://extensions.gnome.org/extension/1285/hotel-manager/
|
||||
[33]:https://github.com/hardpixel/hotel-manager
|
||||
[34]:https://extensions.gnome.org/extension/1207/vscode-search-provider/
|
||||
[35]:https://github.com/jomik/vscode-search-provider
|
||||
[36]:https://fedoramagazine.org/wp-content/uploads/2018/04/vscodesearch.png
|
||||
@ -365,4 +365,4 @@ via: [https://opensource.com/article/18/4/python-datetime-libraries][34]
|
||||
[37]: https://github.com/译者ID
|
||||
[38]: https://github.com/校对者ID
|
||||
[39]: https://github.com/LCTT/TranslateProject
|
||||
[40]: https://linux.cn/
|
||||
[40]: https://linux.cn/
|
||||
116
translated/tech/20171220 Containers without Docker at Red Hat.md
Normal file
116
translated/tech/20171220 Containers without Docker at Red Hat.md
Normal file
@ -0,0 +1,116 @@
|
||||
Red Hat 的去 Docker 化容器实践
|
||||
======
|
||||
|
||||
最近几年，开源项目Docker (已更名为[Moby][1]) 在容器普及化方面建树颇多。然而，它的功能特性不断集中到一个单一、庞大的系统，该系统由具有 root 权限运行的守护进程 `dockerd` 管控，这引发了人们的焦虑。对这些焦虑的阐述，具有代表性的是 Red Hat 公司的容器团队负责人 Dan Walsh 在 [KubeCon \+ CloudNativecon][3] 会议中的[演讲][2]。Walsh讲述了他的容器团队目前的工作方向，即使用一系列更小、可协同工作的组件替代 Docker。他的战斗口号是”拒绝臃肿的守护进程“，理由是与公认的 Unix 哲学相违背。
|
||||
|
||||
### Docker 模块化实践
|
||||
|
||||
就像我们在[早期文献][4]中看到的那样，容器的基础操作不复杂：你首先拉取一个容器镜像，利用该镜像创建一个容器，最后启动这个容器。除此之外，你要懂得如何构建镜像并推送至镜像仓库。大多数人在上述这些步骤中使用 Docker，但其实 Docker 并不是唯一的选择，目前的可替换选择是 `rkt`。rkt引发了一系列标准的创建，包括运行时标准 CRI，镜像标准 OCI 及网络标准 CNI 等。遵守这些标准的后端，如 [CRI-O][5] 和 Docker，可以与 [Kubernetes][6] 为代表的管理软件协同工作。
|
||||
|
||||
这些标准促使 Red Hat 公司开发了一系列部分实现标准的”核心应用“供 Kubernetes 使用，例如 CRI-O 运行时。但 Kubernetes 提供的功能不足以满足 Red Hat公司的 [OpenShift][7] 项目所需。开发者可能需要构建容器并推送至镜像仓库，实现这些操作需要额外的一整套方案。
|
||||
|
||||
事实上，目前市面上已有多种构建容器的工具。来自 Sysdig 公司的 Michael Ducy 在[分会场][8]中回顾了 Docker 本身之外的8种镜像构建工具，而这也很可能不是全部的工具。Ducy 将理想的构建工具定义如下：可以用可重现的方式创建最小化镜像。最小化镜像并不包含操作系统，只包含应用本身及其依赖。Ducy 认为 [Distroless][9], [Smith][10] 及 [Source-to-Image][11] 都是很好的工具，可用于构建最小化镜像。Ducy 将最小化镜像称为”微容器“。
|
||||
|
||||
可重现镜像是指构建多次结果保持不变的镜像。为达到这个目标，Ducy 表示应该使用“宣告式”而不是“命令式”的方式。考虑到 Ducy 来自 Chef 配置管理工具领域，你应该能理解他的意思。Ducy 给出了符合标准的几个不错的实现，包括 [Ansible 容器][12], [Habitat][13], [nixos-容器][14]和 [Simth][10] 等，但你需要了解这些项目对应的编程语言。Ducy 额外指出 Habitat 构建的容器自带管理功能，如果你已经使用了systemd, Docker 或 Kubernetes 等外部管理工具，Habitat 的管理功能可能是冗余的。除此之外，我们还要提从 Docker 和 [Buildah][16] 项目诞生的新项目 [BuildKit][15], 它是 Red Hat 公司 [Atomic 工程][17]的一个组件。
|
||||
|
||||
### 使用Buildah构建容器
|
||||
|
||||
![\[Buildah logo\]][18] Buildah 名称显然来自于 Walsh 风趣的 [Boston 口音][19]; 该工具的品牌宣传中充满了 Boston 风格，例如 logo 使用了 Boston 梗犬(如图所示)。该项目的实现思路与 Ducy 不同：为了构建容器，与其被迫使用宣告式配置管理的方案，不如构建一些简单工具，结合你最喜欢的配置管理工具使用。这样你可以如愿的使用命令行，例如使用 `cp` 命令代替 Docker 的自定义指令 `COPY` 。除此之外，你可以使用如下工具为容器提供内容：1) 配置管理工具，例如Ansible 或 Puppet；2) 操作系统相关或编程语言相关的安装工具，例如 APT 和 pip; 3) 其它系统。下面展示了基于通用 shell 命令的容器构建场景，其中只需要使用 `make` 命令即可为容器安装可执行文件。
|
||||
|
||||
```
|
||||
# 拉取基础镜像, 类似 Dockerfile 中的 FROM 命令
|
||||
buildah from redhat
|
||||
|
||||
# 挂载基础镜像, 在其基础上工作
|
||||
crt=$(buildah mount)
|
||||
ap foo $crt
|
||||
make install DESTDIR=$crt
|
||||
|
||||
# 下一步，生成快照
|
||||
buildah commit
|
||||
|
||||
```
|
||||
|
||||
有趣的是，基于这个思路，你可以复用主机环境中的构建工具，无需在镜像中安装这些依赖，故可以构建非常微小的镜像。通常情况下，构建容器镜像时需要在容器中安装目标应用的构建依赖。例如，从源码构建需要容器中有编译器工具链，这是因为构建并不在主机环境进行。大量的容器也包含了 `ps` 和 `bash` 这样的 Unix 命令，对微容器而言其实是多余的。开发者经常忘记或无法从构建好的容器中移除一些依赖，增加了不必要的开销和攻击面。
|
||||
|
||||
Buildah的模块化方案能够以非 root 方式进行部分构建；但`mount` 命令仍然需要 `CAP_SYS_ADMIN` 或 `等同 root 访问权限` 的能力，有一个 [issue][20] 试图解决该问题。但 Buildah 与 Docker [都有][21]同样的限制[22]，即无法在容器内构建容器。对于 Docker，你需要使用“特权”模式运行容器，一些特殊的环境很难满足这个条件，例如 [GitLab 持续集成][23]；即使满足该条件，配置也特别[繁琐][24]。
|
||||
|
||||
手动提交的步骤可以对创建容器快照的时间节点进行细粒度控制。Dockerfile 每一行都会创建一个新的快照；相比而言，Buildah 的提交检查点都是事先选择好的，这可以减少不必要的快照并节省磁盘空间。这也有利于隔离私钥或密码等敏感信息，避免其出现在公共镜像中。
|
||||
|
||||
Docker 构建的镜像是非标准的、仅供其自身使用；相比而言，Buildah 提供[多种输出格式][25]，其中包括符合 OCI 标准的镜像。为向后兼容，Buildah 提供 一个 `使用Dockerfile构建` 的命令，即 [`buildah bud`][26], 它可以解析标准的 Dockerfile。Buildah 提供 `enter` 命令直接查看镜像内部信息，`run` 命令启动一个容器。实现这些功能仅使用了 `runc` 在内的标准工具，无需在后台运行一个“臃肿的守护进程”。
|
||||
|
||||
Ducy 对 Buildah 表示质疑，认为采用非宣告性不利于可重现性。如果允许使用 shell 命令，可能产生很多预想不到的情况；例如，一个 shell 脚本下载了任意的可执行程序，但后续无法追溯文件的来源。shell 命令的执行受环境变量影响，执行结果可能大相径庭。与基于 shell 的工具相比，Puppet 或 Chef 这样的配置管理系统在理论上更加可靠，因为他们的设计初衷就是收敛于最终配置；事实上，可以通过配置管理系统调用 shell 命令。但 Walsh 对此提出反驳，认为已有的配置管理工具可以在 Buildah 的基础上工作，用户可以选择是否使用配置管理；这样更加符合“机制与策略分离”的经典 Unix 哲学。
|
||||
|
||||
目前 Buildah 处于测试阶段，Red Hat 公司正努力将其集成到 OpenShift。我写这篇文章时已经测试过 Buildah，它缺少一些主题的文档，但基本可以稳定运行。尽管在错误处理方面仍有待提高，但它确实是一款值得你关注的容器工具。
|
||||
|
||||
### 替换其它 Docker 命令行
|
||||
|
||||
Walsh 在其演讲中还简单介绍了 Redhat 公司 正在开发的另一个暂时叫做 [libpod][24] 的项目。项目名称来源于 Kubernetes 中的 “pod”， 在 Kubernetes 中 “pod” 用于分组主机内的容器，分享名字空间等。
|
||||
|
||||
Libpod 提供 `kpod` 命令，用于直接检查和操作容器存储。Walsh 分析了该命令发挥作用的场景，例如 `dockerd` 停止响应或 Kubernetes 集群崩溃。基本上，`kpod` 独立地再次实现了 `docker` 命令行工具。`kpod ps` 返回运行中的容器列表，`kpod images` 返回镜像列表。事实上，[命令转换速查手册][28] 中给出了每一条 Docker 命令对应的 `kpod` 命令。
|
||||
|
||||
这种模块化实现的一个好处是，当你使用 `kpod run` 运行容器时，容器直接作为当前 shell 而不是 `dockerd` 的子进程启动。理论上，可以直接使用 systemd 启动容器，这样可以消除 `dockerd` 引入的冗余。这让[由套接字激活的容器][29]成为可能，但暂时基于 Docker 实现该特性[并不容易][30]，[即使借助 Kubernetes][31] 也是如此。但我在测试过程中发现，使用 `kpod` 启动的容器有一些基础功能性缺失，具体而言是网络功能(!)，相关实现在[活跃开发][32]过程中。
|
||||
|
||||
我们最后提到的命令是 `push`。虽然上述命令已经足以满足本地使用容器的需求，但没有提到远程仓库，借助远程仓库开发者可以活跃地进行应用打包协作。仓库也是持续部署框架的核心组件。[skopeo][33] 项目用于填补这个空白，它是另一个 Atomic 成员项目，按其 `README` 文件描述，“包含容器镜像及镜像库的多种操作”。该项目的设计初衷是，在不用类似 `docker pull` 那样实际下载可能体积庞大的镜像的前提下，检查容器镜像的内容。Docker [拒绝加入][34] 检查功能，建议通过一个额外的工具实现该功能，这促成了 Skopeo 项目。除了`pull`,`push`，Skopeo现在还可以完成很多其它操作，例如在，不产生本地副本的情况下将镜像在不同的仓库中复制和转换。由于部分功能比较基础，可供其它项目使用，目前很大一部分 Skopeo 代码位于一个叫做 [containers/image][35] 的基础库。[Pivotal][36], Google的 [container-diff][37] ,`kpod push` 及 `buildah push` 都使用了该库。
|
||||
|
||||
`kpod` 与 Kubernetes 并没有紧密的联系，故未来可能会更换名称(事实上，在本文刊发过程中，已经更名为 [`podman`][38])，毕竟 Red Hat 法务部门还没有明确其名称。该团队希望实现更多 pod 级别的命令，这样可以对多个容器进行操作，有点类似于 [`docker compose`][39] 实现的功能。但在这方面，[Kompose][40] 是更好的工具，可以通过 [复合 YAML 文件][41] 在 Kubernetes 集群中运行容器。按计划，我们不会实现类似于 [`swarm`] 的 Docker 命令，这部分功能最好由 Kubernetes 本身完成。
|
||||
|
||||
目前看来，已经持续数年的 Docker 模块化努力终将硕果累累。但目前 `kpod` 处于快速迭代过程中，不太适合用于生产环境，但那些工具的众不同的设计理念让人很感兴趣，而且其中大部分的工具已经可以用于开发环境。目前只能通过编译源码的方式安装 libpod，但最终会提供各个发行版的二进制包。
|
||||
|
||||
> 本文[最初发表][43]于 [Linux Weekly News][44]。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
链接: https://anarc.at/blog/2017-12-20-docker-without-docker/
|
||||
|
||||
作者：[À propos de moi][a]
|
||||
译者：[pinewall](https://github.com/pinewall)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://anarc.at
|
||||
[1]:https://mobyproject.org/
|
||||
[2]:https://kccncna17.sched.com/event/CU8j/cri-o-hosted-by-daniel-walsh-red-hat
|
||||
[3]:http://events.linuxfoundation.org/events/kubecon-and-cloudnativecon-north-america
|
||||
[4]:https://lwn.net/Articles/741897/
|
||||
[5]:http://cri-o.io/
|
||||
[6]:https://kubernetes.io/
|
||||
[7]:https://www.openshift.com/
|
||||
[8]:https://kccncna17.sched.com/event/CU6B/building-better-containers-a-survey-of-container-build-tools-i-michael-ducy-chef
|
||||
[9]:https://github.com/GoogleCloudPlatform/distroless
|
||||
[10]:https://github.com/oracle/smith
|
||||
[11]:https://github.com/openshift/source-to-image
|
||||
[12]:https://www.ansible.com/ansible-container
|
||||
[13]:https://www.habitat.sh/
|
||||
[14]:https://nixos.org/nixos/manual/#ch-containers
|
||||
[15]:https://github.com/moby/buildkit
|
||||
[16]:https://github.com/projectatomic/buildah
|
||||
[17]:https://www.projectatomic.io/
|
||||
[18]:https://raw.githubusercontent.com/projectatomic/buildah/master/logos/buildah-logomark_large.png (Buildah logo)
|
||||
[19]:https://en.wikipedia.org/wiki/Boston_accent
|
||||
[20]:https://github.com/projectatomic/buildah/issues/171
|
||||
[21]:https://github.com/projectatomic/buildah/issues/158
|
||||
[22]:https://github.com/moby/moby/issues/27886#issuecomment-281278525
|
||||
[23]:https://about.gitlab.com/features/gitlab-ci-cd/
|
||||
[24]:https://jpetazzo.github.io/2015/09/03/do-not-use-docker-in-docker-for-ci/
|
||||
[25]:https://github.com/projectatomic/buildah/blob/master/docs/buildah-push.md
|
||||
[26]:https://github.com/projectatomic/buildah/blob/master/docs/buildah-bud.md
|
||||
[27]:https://github.com/projectatomic/libpod
|
||||
[28]:https://github.com/projectatomic/libpod/blob/master/transfer.md#development-transfer
|
||||
[29]:http://0pointer.de/blog/projects/socket-activated-containers.html
|
||||
[30]:https://legacy-developer.atlassian.com/blog/2015/03/docker-systemd-socket-activation/
|
||||
[31]:https://github.com/kubernetes/kubernetes/issues/484
|
||||
[32]:https://github.com/projectatomic/libpod/issues/129
|
||||
[33]:https://github.com/projectatomic/skopeo
|
||||
[34]:https://github.com/moby/moby/pull/14258
|
||||
[35]:https://github.com/containers/image
|
||||
[36]:https://pivotal.io/
|
||||
[37]:https://github.com/GoogleCloudPlatform/container-diff
|
||||
[38]:https://github.com/projectatomic/libpod/blob/master/docs/podman.1.md
|
||||
[39]:https://docs.docker.com/compose/overview/#compose-documentation
|
||||
[40]:http://kompose.io/
|
||||
[41]:https://docs.docker.com/compose/compose-file/
|
||||
[42]:https://docs.docker.com/engine/swarm/
|
||||
[43]:https://lwn.net/Articles/741841/
|
||||
[44]:http://lwn.net/
|
||||
@ -1,150 +0,0 @@
|
||||
12 个 Git 提示献给 Git 12 岁生日
|
||||
=====
|
||||
|
||||
|
||||
[Git][1] 是一个分布式版本控制系统，它已经成为开源世界中源代码控制的默认工具，在 4 月 12 日这天，它 12 岁了。使用 Git 令人沮丧的事情之一是你需要知道更多才能有效地使用 Git。这也可能是使用 Git 比较美妙的一件事，因为没有什么比发现一个新技巧来简化或提高你的工作流的效率更令人快乐了。
|
||||
|
||||
为了纪念 Git 的 12 岁生日，这里有 12 条技巧和诀窍来让你的 Git 经验更加有用和强大。从你可能忽略的一些基本知识开始，并扩展到一些真正的高级用户技巧！
|
||||
|
||||
### 1\. 你的 ~/.gitconfig 文件
|
||||
|
||||
当你第一次尝试使用 `git` 命令向仓库提交一个更改时，你可能会收到这样的欢迎信息：
|
||||
```
|
||||
*** Please tell me who you are.
|
||||
|
||||
Run
|
||||
|
||||
git config --global user.email "you@example.com"
|
||||
|
||||
git config --global user.name "Your Name"
|
||||
|
||||
to set your account's default identity.
|
||||
|
||||
```
|
||||
|
||||
你可能没有意识到正是这些命令正在修改 `~/.gitconfig` 的内容，这是 Git 存储全局配置选项的地方。你可以通过 `~/.gitconfig` 文件来做大量的事，包括定义别名，永久性打开（或关闭）特定命令选项，以及修改 Git 工作方式（例如，`git diff` 使用哪个 diff 算法，或者默认使用什么类型的合并策略）。你甚至可以根据仓库的路径有条件地包含其他配置文件！所有细节请参阅 `man git-config`。
|
||||
|
||||
### 2\. 你仓库的 .gitconfig 文件
|
||||
|
||||
在之前的技巧中，你可能想知道 `git config` 命令中 `--global` 标志是干什么的。它告诉 Git 更新 `~/.gitconfig` 中的 "global" 配置。当然，有一个全局配置意味着一个本地配置，确定的是，如果你省略 `--global` 标志，`git config` 将改为更新仓库特有的配置，该配置在 `.git/config` 中。
|
||||
|
||||
在 `.git/config` 文件中设置的选项将覆盖 `〜/.gitconfig` 文件中的所有设置。因此，例如，如果你需要为特定仓库使用不同的电子邮件地址，则可以运行 `git config user.email "also_you@example.com"`。然后，该仓库中的任何提交都将使用你单独配置的电子邮件地址。如果你在开源项目中工作，而且希望他们显示自己的电子邮件地址，同时仍然使用自己工作邮箱作为主 Git 配置，这非常有用。
|
||||
|
||||
几乎任何你可以在 `〜/ .gitconfig` 中设置的东西，你也可以在 `.git / config` 中进行设置，以使其作用于特定的仓库。在线面的提示中，当我提到将某些内容添加到 `~/.gitconfig` 时，只需记住你也可以在特定仓库的 `.git/config` 中添加来设置那个选项。
|
||||
|
||||
### 3\. 别名
|
||||
|
||||
别名是你可以在 `〜/ .gitconfig` 中做的另一件事。它的工作原理就像命令行中的 shell -- 它们设定一个新的命令名称，可以调用一个或多个其他命令，通常使用一组特定的选项或标志。它们对于那些你经常使用的又长又复杂的命令来说非常有效。
|
||||
|
||||
你可以使用 `git config` 命令来定义别名 - 例如，运行 `git config --global --add alias.st status` 将使运行 `git st` 与运行 `git status` 做同样的事情 - 但是我在定义别名时发现，直接编辑 `~/.gitconfig` 文件通常更容易。
|
||||
|
||||
如果你选择使用这种方法，你会发现 `~/.gitconfig` 文件是一个 [INI 文件][2]。INI 是一种带有特定段落的键值对文件格式。当添加一个别名时，你将改变 `[alias]` 段落。例如，定义上面相同的 `git st` 别名时，添加如下到文件：
|
||||
```
|
||||
[alias]
|
||||
|
||||
st = status
|
||||
|
||||
```
|
||||
|
||||
（如果已经有 `[alias]` 段落，只需将第二行添加到现有部分。）
|
||||
|
||||
### 4\. shell 命令中的别名
|
||||
|
||||
别名不仅仅限于运行其他 Git 子 命令 - 你还可以定义运行其他 shell 命令的别名。这是一个很好的方式来处理一个反复发生的，罕见和复杂的任务：一旦你确定了如何完成它，就可以在别名下保存该命令。例如，我有一些仓库，我已经 fork 了一个开源的项目并进行了一些本地修改。我想跟上项目正在进行的开发工作，并保存我本地的变化。为了实现这个目标，我需要定期将来自上游仓库的更改合并到我 fork 的项目中 - 我通过使用我称之为 `upstream-merge` 的别名。它是这样定义的：
|
||||
```
|
||||
upstream-merge = !"git fetch origin -v && git fetch upstream -v && git merge upstream/master && git push"
|
||||
|
||||
```
|
||||
|
||||
别名定义开头的 `!` 告诉 Git 通过 shell 运行这个命令。这个例子涉及到运行一些 `git` 命令，但是以这种方式定义的别名可以运行任何 shell 命令。
|
||||
|
||||
（注意，如果你想复制我的 `upstream-merge` 别名，你需要确保你有一个名为 `upstream` 的 Git remote 指向你已经分配的上游仓库，你可以通过运行 `git remote add upstream <URL to repo>` 来添加一个。）
|
||||
|
||||
### 5\. 可视化提交图
|
||||
|
||||
如果你从事的是一个有很多分支活动的项目，有时可能很难掌握所有正在发生的工作以及它们之间的相关性。各种图形用户界面工具可让你获取不同分支的图片并在所谓的“提交图表”中提交。例如，以下是我使用 [GitLab][3] 提交图表查看器可视化的我的一个仓库的一部分：
|
||||
|
||||
![GitLab commit graph viewer][5]
|
||||
John Anderson, CC BY
|
||||
|
||||
如果你是一个专注于命令行的用户或者某个发现切换工具让人分心，那么最好从命令行获得类似的提交视图。这就是 `git log` 命令的 `--graph` 参数出现的地方：
|
||||
|
||||
![Repository visualized with --graph command][7]
|
||||
|
||||
John Anderson, CC BY
|
||||
|
||||
以下命令可视化相同仓库可达到相同效果：
|
||||
```
|
||||
git log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative
|
||||
|
||||
```
|
||||
|
||||
`--graph` 选项将图添加到日志的右侧，`--abbrev-commit` 缩短提交的 [SHAs][8] 值，`--date=relative` 用相对属于表示日期，以及 `--pretty` 位处理所有其他自定义格式。我有 `git lg` 别名用于这个功能，它是我最常用的 10 个命令之一。
|
||||
|
||||
### 6\. 更优雅的强制推送
|
||||
|
||||
有时，就像你试图避免使用它一样困难的是，你会发现你需要运行 `git push --force` 来覆盖仓库远程副本上的历史记录。你可能得到了一些反馈，导致你进行交互式重新分配，或者你可能已经搞砸了，并希望隐藏证据。
|
||||
|
||||
当其他人在仓库的远程副本的同一分支上进行更改时，会发生强制推送的危险。当你强制推送已重写的历史记录时，这些提交将会丢失。这就是 `git push --force-with-lease` 出现的原因 -- 如果远程分支已经丢失，它不会允许你强制推送，这确保你不会丢掉别人的工作。
|
||||
|
||||
### 7\. git add -N
|
||||
|
||||
你是否过 `git commit -a` 在一次行动中提交所有未完成的修改，只有在你推送完提交后才发现 `git commit -a` 忽略了新添加的文件才能发现？你可以使用 `git add -N` (想想 "notify") 来解决这个问题，告诉 Git 在第一次实际提交它们之前，你希望在提交中包含新增文件。
|
||||
|
||||
### 8\. git add -p
|
||||
|
||||
使用 Git 时的最佳做法是确保每次提交都只包含一个逻辑修改 - 无论这是修复错误还是添加新功能。然而，有时当你在工作时，你的仓库最终会有多个提交值的修改。你怎样才能设法把事情分开，使每个提交只包含适当的修改呢？`git add --patch` 来拯救你了！
|
||||
|
||||
这个标志会让 `git add` 命令查看你工作副本中的所有变化，并为每个变化询问你是否想要将它提交，跳过，或者推迟决定（以及其他更强大的选项，你可以在运行命令后选择 `?` 来查看）。`git add -p` 是生成结构良好的提交的绝佳工具。
|
||||
|
||||
### 9\. git checkout -p
|
||||
|
||||
与 `git add -p` 类似，`git checkout` 命令将采用 `--patch` 或 `-p` 选项，这会使其在本地工作副本中显示每个“大块”的改动，并允许丢弃它 -- 简单来说就是将本地工作副本恢复到更改之前的状态。
|
||||
|
||||
这真的很棒。例如，当你追踪一个 bug 时引入了一堆调试日志语句，修正了这个 bug 之后，你可以先使用 `git checkout -p` 移除所有新的调试日志，然后 `git add -p` 来添加 bug 修复。没有比组合一个优雅的，结构良好的提交更令人满意！
|
||||
|
||||
### 10\. Rebase 时执行命令
|
||||
|
||||
有些项目有一个规则，即存储库中的每个提交都必须处于工作状态 - 也就是说，在每次提交时，应该可以编译代码，或者应该运行测试套件而不会失败。 当你在分支上工作时，这并不困难，但是如果你最终因为某种原因需要 rebase 时，那么逐步完成每个重新绑定的提交以确保你没有意外地引入一个中断是乏味的。
|
||||
|
||||
幸运的是，`git rebase` 已经覆盖了 `-x` 或 `--exec` 选项。`git rebase -x <cmd>` 将在每次提交应用到 rebase 后运行该命令。因此，举个例子，如果你有一个项目，其中 `npm run tests` 运行你的测试套件，`git rebase -x npm run tests` 将在 rebase 期间每次提交之后运行测试套件。这使你可以查看测试套件是否在任何重新发布的提交中失败，因此你可以确认测试套件在每次提交时仍能通过。
|
||||
|
||||
### 11\. 基于时间的修正参考
|
||||
|
||||
很多 Git 子命令都接受一个修正的参数来决定命令作用于仓库的哪个部分，可以是某次特定的提交的 sha1 值，一个分支的名称，甚至是一个符号性的名称如 `HEAD`（代表当前检出分支最后一次的提交），除了这些简单的形式以外，你还可以附加一个指定的日期或时间作为参数，表示“这个时间的引用”。
|
||||
|
||||
这个功能在某些时候会变得十分有用。当你处理最新出现的 bug，自言自语道：“这个功能昨天还是好好的，到底又改了些什么”，不用盯着满屏的 `git log` 的输出试图弄清楚什么时候更改了提交，你只需运行 `git diff HEAD@{yesterday}`，看看从昨天以来的所有修改。这也适用于更长的时间段（例如 `git diff HEAD@{'2 months ago'}`），以及一个确切的日期（例如 `git diff HEAD@{'2010-01-01 12:00:00'}`）。
|
||||
|
||||
你也可以将这些基于日期的修改参数与使用修正参数的任何 Git 子命令一起使用。在 `gitrevisions` 手册页中有关于具体使用哪种格式的详细信息。
|
||||
|
||||
### 12\. 能知道所有的 reflog
|
||||
|
||||
你是不是试过在 rebase 时干掉过某次提交，然后发现你需要保留那个提交中一些东西？你可能觉得这些信息已经永远找不回来了，只能重新创建。但是如果你在本地工作副本中提交了，提交就会被添加到引用日志（reflog）中 ，你仍然可以访问到。
|
||||
|
||||
运行 `git reflog` 将在本地工作副本中显示当前分支的所有活动的列表，并为你提供每个提交的 SHA1 值。一旦发现你 rebase 时放弃的那个提交，你可以运行 `git checkout <SHA1>` 跳转到该提交，复制任何你需要的信息，然后再运行 `git checkout HEAD` 返回到分支最近的提交去。
|
||||
|
||||
### 以上是全部内容
|
||||
|
||||
希望这些技巧中至少有一个能够教给你一些关于 Git 的新东西，Git 是一个有12年历史的项目，并且在持续创新和增加新功能中。你最喜欢的 Git 技巧是什么？
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/18/4/12-git-tips-gits-12th-birthday
|
||||
|
||||
作者：[John SJ Anderson][a]
|
||||
译者：[MjSeven](https://github.com/MjSeven)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
选题：[lujun9972](https://github.com/lujun9972)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://opensource.com/users/genehack
|
||||
[1]:https://git-scm.com/
|
||||
[2]:https://en.wikipedia.org/wiki/INI_file
|
||||
[3]:https://gitlab.com/
|
||||
[4]:/file/392941
|
||||
[5]:https://opensource.com/sites/default/files/styles/panopoly_image_original/public/u128651/gui_graph.png?itok=3GovYfG1 (GitLab commit graph viewer)
|
||||
[6]:/file/392936
|
||||
[7]:https://opensource.com/sites/default/files/styles/panopoly_image_original/public/u128651/console_graph.png?itok=XogY1P8M (Repository visualized with --graph command)
|
||||
[8]:https://en.wikipedia.org/wiki/Secure_Hash_Algorithms
|
||||
@ -0,0 +1,166 @@
|
||||
给初学者看的 Shuf 命令教程
|
||||
======
|
||||
|
||||
|
||||
Shuf 命令用于在类 Unix 操作系统中生成随机排列。使用 shuf 命令，我们可以随机打乱给定输入文件的行。Shuf 命令是 GNU Coreutils 的一部分，因此你不必担心安装问题。在这个简短的教程中，让我向你展示一些 shuf 命令的例子。
|
||||
|
||||
### 带例子的 Shuf 命令教程
|
||||
|
||||
我有一个名为 **ostechnix.txt** 的文件，内容如下。
|
||||
```
|
||||
$ cat ostechnix.txt
|
||||
line1
|
||||
line2
|
||||
line3
|
||||
line4
|
||||
line5
|
||||
line6
|
||||
line7
|
||||
line8
|
||||
line9
|
||||
line10
|
||||
|
||||
```
|
||||
|
||||
现在让我们以随机顺序显示上面的行。为此，请运行：
|
||||
```
|
||||
$ shuf ostechnix.txt
|
||||
line2
|
||||
line8
|
||||
line5
|
||||
line10
|
||||
line7
|
||||
line1
|
||||
line4
|
||||
line6
|
||||
line9
|
||||
line3
|
||||
|
||||
```
|
||||
|
||||
看到了吗？上面的命令将名为 “ostechnix.txt” 中的行随机排列并输出了结果。
|
||||
|
||||
你可能想将输出写入另一个文件。例如，我想将输出保存到 **output.txt** 中。为此，请先创建 output.txt：
|
||||
```
|
||||
$ touch output.txt
|
||||
|
||||
```
|
||||
|
||||
然后，像下面使用 **-o** 标志将输出写入该文件。
|
||||
```
|
||||
$ shuf ostechnix.txt -o output.txt
|
||||
|
||||
```
|
||||
|
||||
上面的命令将随机随机打乱 ostechnix.txt 的内容并将输出写入 output.txt。你可以使用命令查看 output.txt 的内容：
|
||||
```
|
||||
$ cat output.txt
|
||||
|
||||
line2
|
||||
line8
|
||||
line9
|
||||
line10
|
||||
line1
|
||||
line3
|
||||
line7
|
||||
line6
|
||||
line4
|
||||
line5
|
||||
|
||||
```
|
||||
|
||||
我只想显示文件中的任意一行。我该怎么做？很简单！
|
||||
```
|
||||
$ shuf -n 1 ostechnix.txt
|
||||
line6
|
||||
|
||||
```
|
||||
|
||||
同样，我们可以选择前 “n” 个随机条目。以下命令将只显示前五个随机条目。
|
||||
```
|
||||
$ shuf -n 5 ostechnix.txt
|
||||
line10
|
||||
line4
|
||||
line5
|
||||
line9
|
||||
line3
|
||||
|
||||
```
|
||||
|
||||
如下所示，我们可以直接使用 **-e** 标志传入输入，而不是从文件中读取行。
|
||||
```
|
||||
$ shuf -e line1 line2 line3 line4 line5
|
||||
line1
|
||||
line3
|
||||
line5
|
||||
line4
|
||||
line2
|
||||
|
||||
```
|
||||
|
||||
你也可以传入数字：
|
||||
```
|
||||
$ shuf -e 1 2 3 4 5
|
||||
3
|
||||
5
|
||||
1
|
||||
4
|
||||
2
|
||||
|
||||
```
|
||||
|
||||
要快速在给定范围选择一个，请改用此命令。
|
||||
```
|
||||
$ shuf -n 1 -e 1 2 3 4 5
|
||||
|
||||
```
|
||||
|
||||
或者，选择下面的任意三个随机数字。
|
||||
```
|
||||
$ shuf -n 3 -e 1 2 3 4 5
|
||||
3
|
||||
5
|
||||
1
|
||||
|
||||
```
|
||||
|
||||
我们也可以在特定范围内生成随机数。例如，要显示 1 到 10 之间的随机数，只需使用：
|
||||
```
|
||||
$ shuf -i 1-10
|
||||
1
|
||||
9
|
||||
8
|
||||
2
|
||||
4
|
||||
7
|
||||
6
|
||||
3
|
||||
10
|
||||
5
|
||||
|
||||
```
|
||||
|
||||
有关更多详细信息，请参阅手册页。
|
||||
```
|
||||
$ man shuf
|
||||
|
||||
```
|
||||
|
||||
今天就是这些。还有更多更好的东西。敬请关注！
|
||||
|
||||
干杯!
|
||||
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.ostechnix.com/the-shuf-command-tutorial-with-examples-for-beginners/
|
||||
|
||||
作者：[SK][a]
|
||||
译者：[geekpi](https://github.com/geekpi)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
选题：[lujun9972](https://github.com/lujun9972)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://www.ostechnix.com/author/sk/
|
||||
@ -0,0 +1,126 @@
|
||||
对开发者来说非常好的GNOME扩展
|
||||
======
|
||||
|
||||
|
||||
这个扩展给与了 GNOME3 桌面环境以非常大的灵活性，这种灵活性赋予了用户在定制化桌面上的优势，从而使他们的工作流程变得更加舒适和有效率。Fedora 系统已经已经包含了一部分例如 EasyScreenCast, gTile, 和 OpenWeather 这样很好的桌面扩展，本文接下来会重点报道这些为开发者而改变的扩展。
|
||||
|
||||
如果你需要帮助来安装 GNOME 扩展，那么可以参考《如何安装一个 GNOME 命令行扩展》这篇文章。
|
||||
|
||||
### ![Docker Integration extension icon][5] Docker Integration
|
||||
|
||||
![Docker Integration extension status menu][6]
|
||||
|
||||
对于为自己的应用使用 docker 的开发者而言，这个 docker 集成扩展是必不可少的。这个状态菜单提供了一个带着启动、停止、暂停、甚至删除的这些选项的 docker 容器的列表，这个列表会在新容器加入到这个系统时自动更新。
|
||||
|
||||
在安装完这些扩展后，Fedora 用户可能会收到这么一条消息：“加载容器时发生错误”。这是因为 docker 命令需要在命令前加 sudo，或者得到默认的 root 权限。去设置你的用户权限再去运行 docker，可以参考 Fedora 门户网站上的 docker 安装这一页。
|
||||
|
||||
你可以在这个扩展的站点上找到更多的信息。
|
||||
|
||||
### ![Jenkins CI Server Indicator icon][10] Jenkins CI Server Indicator
|
||||
|
||||
![Jenkins CI Server Indicator extension status menu][11]
|
||||
|
||||
Jenkins CI 服务器指向仪这个扩展使开发者把他们的应用建立在 Jenkins CI 服务器上的这个过程更加简单，它展示了一个菜单，菜单中有一个带有进程和进程状态的列表。他同样包含了很多特点，比如很容易就能创建 Jenkins 的前端，为完整的进程做通知，而且能够触发或者过滤进程。
|
||||
|
||||
如果想要更多的信息，请去浏览开发者站点。
|
||||
|
||||
### ![android-tool extension icon][14] android-tool
|
||||
|
||||
Android-tool 对于 Android 开发者来说会是一个非常有价值的扩展，它的特点包括捕捉错误报告，设备截屏和屏幕录像。它可以通过 usb 和 tcp 连接两种方式来连接 Android 设备。
|
||||
|
||||
这个扩展需要 adb 的包，从 Fedora 官方仓库安装 adb 只需要运行这条命令：
|
||||
```
|
||||
sudo dnf install android-tools
|
||||
|
||||
```
|
||||
|
||||
你可以在这个扩展的 GitHub 网页里找到更多信息。
|
||||
|
||||
### ![GnomeHub extension icon][19] GnomeHub
|
||||
|
||||
对于为自己的项目使用 GitHub 的 GNOME 用户来说，GnomeHub 是一个非常好的扩展，它可以显示 Github 上的仓库，还可以通知用户有新提交的 pull requests。除此之外，用户可以把他们最喜欢的仓库加在这个扩展的设置里。
|
||||
|
||||
如果想要更多信息，可以参考一下这个项目的 GitHub 页面。
|
||||
|
||||
### ![gistnotes extension icon][23] gistnotes
|
||||
|
||||
简单地说，gistnotes 为 gist 用户提供了一种简单的方式来创建、存储和管理注释和代码片段。如果想要更多的信息，可以参考这个项目的网站。
|
||||
|
||||
![gistnotes window][26]
|
||||
|
||||
### ![Arduino Control extension icon][27] Arduino Control
|
||||
|
||||
这个 Arduino 控制扩展允许用户去连接或者控制他们自己的单片机电路板，它同样允许用户在状态菜单里增加滑块或者开关。除此之外，开发者模式允许扩展目录里的脚本通过以太网或者 usb 来连接电路板。
|
||||
|
||||
最重要的是，这个扩展可以被定制化来适合你的项目，在 README 文件里的例子是，它能够“通过网络上任意的电脑来控制你房间里的灯”。
|
||||
|
||||
你可以从这个项目的 GitHub 页面上得到更多的产品信息并安装这个扩展。
|
||||
|
||||
### ![Hotel Manager extension icon][30] Hotel Manager
|
||||
|
||||
![Hotel Manager extension status menu.][31]
|
||||
|
||||
使用 Hotel process manager 开发网站的开发人员，应该尝试一下 Hotel Manager 这个扩展。它展示了一个增加到 hotel 里的网页应用的列表，并给与了用户去开始、停止和重启这些应用的能力。
|
||||
此外，还可以通过电脑图标快速打开、浏览这些网页应用。这个扩展同样可以启动、停止或重启 hotel 的后台程序。
|
||||
|
||||
作为本文的出版物，GNOME 3.26 版本的 Hotel Manager 版本 4 没有在扩展的下拉式菜单里列出网页应用。版本 4 还会在 Fedora 28 (GNOME 3.28) 上安装时报错。然而，版本 3 工作在 Fedora 27 和 Fedora 28。
|
||||
|
||||
如果想要更多细节，可以去看这个项目在 GitHub 上的网页。
|
||||
|
||||
### VSCode Search Provider
|
||||
|
||||
VSCode Search Provider 是一个简单的扩展，它能够在 GNOME 综合搜索结果里展示可视化工作代码项目。对于大部分的 VSCode 用户来说，这个扩展可以让用户快速连接到他们的项目，从而节省时间。你可以从这个项目在 GitHub 上的页面来得到更多的信息。
|
||||
|
||||
![GNOME Overview search results showing VSCode projects.][36]
|
||||
|
||||
在开发环境方面，你有没有一个最喜欢的扩展呢？发在评论区里，一起来讨论下吧。
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://fedoramagazine.org/awesome-gnome-extensions-developers/
|
||||
|
||||
作者：[Shaun Assam][a]
|
||||
译者：[hopefully2333](https://github.com/hopefully2333)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
选题：[lujun9972](https://github.com/lujun9972)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://fedoramagazine.org/author/sassam/
|
||||
[1]:https://fedoramagazine.org/screencast-gnome-extension/
|
||||
[2]:https://fedoramagazine.org/must-have-gnome-extension-gtile/
|
||||
[3]:https://fedoramagazine.org/weather-updates-openweather-gnome-shell-extension/
|
||||
[4]:https://fedoramagazine.org/install-gnome-shell-extension/
|
||||
[5]:https://fedoramagazine.org/wp-content/uploads/2017/08/dockericon.png
|
||||
[6]:https://fedoramagazine.org/wp-content/uploads/2017/08/docker-extension-menu.png
|
||||
[7]:https://extensions.gnome.org/extension/1065/docker-status/
|
||||
[8]:https://developer.fedoraproject.org/tools/docker/docker-installation.html
|
||||
[9]:https://github.com/gpouilloux/gnome-shell-extension-docker
|
||||
[10]:https://fedoramagazine.org/wp-content/uploads/2017/08/jenkinsicon.png
|
||||
[11]:https://fedoramagazine.org/wp-content/uploads/2017/08/jenkins-extension-menu.png
|
||||
[12]:https://extensions.gnome.org/extension/399/jenkins-ci-server-indicator/
|
||||
[13]:https://www.philipphoffmann.de/gnome-3-shell-extension-jenkins-ci-server-indicator/
|
||||
[14]:https://fedoramagazine.org/wp-content/uploads/2017/08/androidtoolicon.png
|
||||
[15]:https://fedoramagazine.org/wp-content/uploads/2017/08/android-tool-extension-menu.png
|
||||
[16]:https://extensions.gnome.org/extension/1232/android-tool/
|
||||
[17]:https://fedoramagazine.org/howto-use-sudo/
|
||||
[18]:https://github.com/naman14/gnome-android-tool
|
||||
[19]:https://fedoramagazine.org/wp-content/uploads/2017/08/gnomehubicon.png
|
||||
[20]:https://fedoramagazine.org/wp-content/uploads/2017/08/gnomehub-extension-menu.png
|
||||
[21]:https://extensions.gnome.org/extension/1263/gnomehub/
|
||||
[22]:https://github.com/lagartoflojo/gnomehub
|
||||
[23]:https://fedoramagazine.org/wp-content/uploads/2017/08/gistnotesicon.png
|
||||
[24]:https://extensions.gnome.org/extension/917/gistnotes/
|
||||
[25]:https://github.com/mohan43u/gistnotes
|
||||
[26]:https://fedoramagazine.org/wp-content/uploads/2018/04/gistnoteswindow.png
|
||||
[27]:https://fedoramagazine.org/wp-content/uploads/2017/08/arduinoicon.png
|
||||
[28]:https://extensions.gnome.org/extension/894/arduino-control/
|
||||
[29]:https://github.com/simonthechipmunk/arduinocontrol
|
||||
[30]:https://fedoramagazine.org/wp-content/uploads/2017/08/hotelicon.png
|
||||
[31]:https://fedoramagazine.org/wp-content/uploads/2017/08/hotelmanager-extension-menu.png
|
||||
[32]:https://extensions.gnome.org/extension/1285/hotel-manager/
|
||||
[33]:https://github.com/hardpixel/hotel-manager
|
||||
[34]:https://extensions.gnome.org/extension/1207/vscode-search-provider/
|
||||
[35]:https://github.com/jomik/vscode-search-provider
|
||||
[36]:https://fedoramagazine.org/wp-content/uploads/2018/04/vscodesearch.png
|
||||
Loading…
Reference in New Issue
Block a user