mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-01-13 22:30:37 +08:00
Merge remote-tracking branch 'LCTT/master'
This commit is contained in:
Xingyu Wang
commit
4c2451f30a
@ -1,8 +1,8 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (robsean)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: reviewer: (wxy)
|
||||
[#]: publisher: (wxy)
|
||||
[#]: url: (https://linux.cn/article-12956-1.html)
|
||||
[#]: subject: (3 Ways to Install Deb Files on Ubuntu Linux)
|
||||
[#]: via: (https://itsfoss.com/install-deb-files-ubuntu)
|
||||
[#]: author: (Abhishek Prakash https://itsfoss.com/author/abhishek/)
|
||||
@ -10,17 +10,13 @@
|
||||
在 Ubuntu Linux 上安装 Deb 文件的 3 种方法
|
||||
======
|
||||
|
||||
**这篇初学者文章解释了如何在 Ubuntu 中安装 deb 软件包。它稍后也向你展示如何移除这些 deb 软件包。**
|
||||
> 这篇初学者文章解释了如何在 Ubuntu 中安装 deb 软件包。它稍后也向你展示如何移除这些 deb 软件包。
|
||||
|
||||
这是 Ubuntu 初学者系列的另一篇文章。如果你对 Ubuntu 很陌生，你可能会想知道 [如何安装应用程序][1]。
|
||||
|
||||
最简单的方法是使用 Ubuntu 软件中心。在软件中心中搜索应用程序的名称并安装它。
|
||||
最简单的方法是使用 Ubuntu 软件中心。在软件中心中搜索应用程序的名称并安装它。如果你能在软件中心中找到所有的应用程序，那么生活就太惬意了。但是，不幸的是，这是不可能的发生的。
|
||||
|
||||
如果你能在软件中心中找到所有的应用程序，那么生活就太惬意了。但是，不幸的是，这是不可能的发生的。
|
||||
|
||||
一些软件包可以通过 DEB 软件包的形式获得。它们是以 .deb 扩展名为结尾的存档文件。
|
||||
|
||||
你可以把 .deb 文件看作为 Windows 中的 .exe 文件。在 Windows 中，你双击 .exe 文件，它将开始安装过程。DEB 软件包也是非常类似的。
|
||||
一些软件包可以通过 DEB 软件包的形式获得。它们是以 .deb 扩展名为结尾的存档文件。你可以把 .deb 文件看作为 Windows 中的 .exe 文件。在 Windows 中，你双击 .exe 文件，它将开始安装过程。DEB 软件包也是非常类似的。
|
||||
|
||||
你可以从软件提供商网站的下载区域找到这些 DEB 软件包。例如，如果你想 [在 Ubuntu 上安装 Google Chrome][2] ，你可以从它的网站下载 Chrome 的 DEB 软件包。
|
||||
|
||||
@ -36,7 +32,7 @@
|
||||
|
||||
#### 方法 1: 使用默认的软件中心
|
||||
|
||||
在 Ubuntu 中，最简单的方法是使用默认的软件中心。在这里你不必要做任何特别的事。只需要转到你所下载的 .deb 文件的文件夹下 (它应该是 Downloads 文件夹)，并在这个文件上双击。
|
||||
在 Ubuntu 中，最简单的方法是使用默认的软件中心。在这里你不必要做任何特别的事。只需要转到你所下载的 .deb 文件的文件夹下（它应该是 Downloads 文件夹），并在这个文件上双击。
|
||||
|
||||
![在 Ubuntu 上的 Google Chrome 的 deb 文件][4]
|
||||
|
||||
@ -56,9 +52,9 @@
|
||||
|
||||
现在，你已经知道 .deb 文件可以简单地通过软件中心来安装，接下来，让我告诉你一些软件包可能会遇到的依赖项的错误。
|
||||
|
||||
发生的原因是，一个程序可能依赖于另外一个软件包（库）。当开发者为你准备 DEB 软件包时，他/她可能会假设你的系统中已经有了所依赖的软件包（库）。
|
||||
发生错误的原因是，一个程序可能依赖于另外一个软件包（库）。当开发者为你准备 DEB 软件包时，他/她可能会假设你的系统中已经有了所依赖的软件包（库）。
|
||||
|
||||
但是如果情况并不是这样的，你的系统没有这些所需要的软件包（库），你将遇到臭名昭著的 ‘依赖项错误’ 。
|
||||
但是如果情况并不是这样的，你的系统没有这些所需要的软件包（库），你将遇到臭名昭著的“依赖项错误”。
|
||||
|
||||
软件中心不能处理这样的错误，因此你不得不使用另外一个名称为 [gdebi][6] 的工具。
|
||||
|
||||
@ -68,8 +64,6 @@ gdebi 是一个轻量级的 GUI 应用程序，它只有安装 deb 软件包的
|
||||
|
||||
![gdebi 在安装 deb 软件包时处理依赖项][7]
|
||||
|
||||
图像致谢: [Xmodulo][8]
|
||||
|
||||
就我个人而言，我更喜欢使用 gdebi 而不是使用软件包中心来安装 deb 文件。它是一个轻量级应用程序，因此安装过程看起来更快一点。更多的信息，你可以阅读[使用 gDebi ，并使其成为安装 DEB 软件包的默认设置][6]。
|
||||
|
||||
你可以从软件中心或使用下面的命令来安装 gdebi ：
|
||||
@ -80,26 +74,24 @@ sudo apt install gdebi
|
||||
|
||||
#### 方法 3: 在命令行中使用 dpkg 安装 .deb 文件
|
||||
|
||||
如果你想在命令行中安装 deb 软件包，你可以使用 apt 命令或者 dpkg 命令。实际上，apt 命令在底层上使用 [dpkg][9] 命令，但是 apt 却更流行和易于使用。
|
||||
如果你想在命令行中安装 deb 软件包，你可以使用 `apt` 命令或者 `dpkg` 命令。实际上，`apt` 命令在底层上使用 [dpkg][9] 命令，但是 `apt` 却更流行和易于使用。
|
||||
|
||||
如果你想对 deb 文件使用 apt 命令，像这样使用它：
|
||||
如果你想对 deb 文件使用 `apt` 命令，像这样使用它：
|
||||
|
||||
```
|
||||
sudo apt install path_to_deb_file
|
||||
```
|
||||
|
||||
如果你想对将要安装的 deb 软件包使用 dpkg 命令，在这里是如何完成它：
|
||||
如果你想对将要安装的 deb 软件包使用 `dpkg` 命令，在这里是如何完成它：
|
||||
|
||||
```
|
||||
sudo dpkg -i path_to_deb_file
|
||||
```
|
||||
|
||||
在这两个命令中，你应该使用你已下载的 deb 文件的路径和名称来替换 path_to_deb_file 。
|
||||
在这两个命令中，你应该使用你已下载的 deb 文件的路径和名称来替换 `path_to_deb_file` 。
|
||||
|
||||
![在 Ubuntu 中使用 dpkg 命令安装 deb 文件][10]
|
||||
|
||||
在 Ubuntu 中使用 dpkg 命令安装 deb 文件。
|
||||
|
||||
如果你在安装 deb 软件包的过程中得到一个依赖项的错误，你可以使用下面的命令来修复依赖项的问题：
|
||||
|
||||
```
|
||||
@ -112,15 +104,15 @@ sudo apt install -f
|
||||
|
||||
#### 方法 1: 使用 apt 命令移除 deb 软件包
|
||||
|
||||
你所需要的全部东西就是你所已安装程序的名称，接下来你可以使用 apt 或 dpkg 来移除这个程序。
|
||||
你所需要的全部东西就是你所已安装程序的名称，接下来你可以使用 `apt` 或 `dpkg` 来移除这个程序。
|
||||
|
||||
```
|
||||
sudo apt remove program_name
|
||||
```
|
||||
|
||||
现在，问题来了，在移除命令中，你如何找到你所需要使用的准确的程序名称？为此，apt 命令也有一个解决方案。
|
||||
现在，问题来了，在移除命令中，你如何找到你所需要使用的准确的程序名称？为此，`apt` 命令也有一个解决方案。
|
||||
|
||||
你可以使用 apt 命令找到所有已安装文件的列表，但是手动完成这一过程将会是一件令人头疼的事。因此，你可以使用 grep 命令来搜索你的软件包。
|
||||
你可以使用 `apt` 命令找到所有已安装文件的列表，但是手动完成这一过程将会是一件令人头疼的事。因此，你可以使用 `grep` 命令来搜索你的软件包。
|
||||
|
||||
例如，在先前的部分中，我已安装 AppGrid 应用程序，但是如果我想知道准确的程序名称，我可以像这样使用一些东西：
|
||||
|
||||
@ -128,7 +120,7 @@ sudo apt remove program_name
|
||||
sudo apt list --installed | grep grid
|
||||
```
|
||||
|
||||
这将给予我全部的名称中含有 grid 的软件包，从这里，我可以得到准确的程序名称。
|
||||
这将给予我全部的名称中含有 “grid” 的软件包，从这里，我可以得到准确的程序名称。
|
||||
|
||||
```
|
||||
apt list --installed | grep grid
|
||||
@ -136,17 +128,17 @@ WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
|
||||
appgrid/now 0.298 all [installed,local]
|
||||
```
|
||||
|
||||
正如你所看到的，一个名称为 appgrid 的软件包已经安装。现在，你可以在 apt remove 命令中使用这个程序名称。
|
||||
正如你所看到的，一个名称为 “appgrid” 的软件包已经安装。现在，你可以在 `apt remove` 命令中使用这个程序名称。
|
||||
|
||||
#### 方法2: 使用 dpkg 命令移除 deb 软件包
|
||||
|
||||
你可以使用 dpkg 来找到已安装程序的名称：
|
||||
你可以使用 `dpkg` 来找到已安装程序的名称：
|
||||
|
||||
```
|
||||
dpkg -l | grep grid
|
||||
```
|
||||
|
||||
该输出将给予所有的名称中有 grid 的软件包。
|
||||
该输出将给予所有的名称中有 “grid” 的软件包。
|
||||
|
||||
```
|
||||
dpkg -l | grep grid
|
||||
@ -154,18 +146,19 @@ dpkg -l | grep grid
|
||||
ii appgrid 0.298 all Discover and install apps for Ubuntu
|
||||
```
|
||||
|
||||
ii 在上面的命令输出中意味着软件包已经被正确地安装。
|
||||
在上面的命令输出中的 `ii` 意味着软件包已经被正确地安装。
|
||||
|
||||
现在，你有了程序名称，你可以使用 dpkg 命令来移除它：
|
||||
现在，你有了程序名称，你可以使用 `dpkg` 命令来移除它：
|
||||
|
||||
```
|
||||
dpkg -r program_name
|
||||
```
|
||||
|
||||
**提示：更新 deb 软件包**
|
||||
|
||||
一些 deb 软件包 （像 Chrome）通过系统更新来提供其更新，但是对于大多数的其它的程序，你将不得不先移除已存在的程序，并在接下来安装更新的版本。
|
||||
|
||||
我希望这篇初学者指南能够帮助你在 Ubuntu 上安装 deb 软件包。我添加移除部分，以便你可以更好地控制你所安装的程序。
|
||||
我希望这篇初学者指南能够帮助你在 Ubuntu 上安装 deb 软件包。我添加了移除部分，以便你可以更好地控制你所安装的程序。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
@ -173,8 +166,8 @@ via: https://itsfoss.com/install-deb-files-ubuntu
|
||||
|
||||
作者：[Abhishek Prakash][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
译者：[robsean](https://github.com/robsean)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
@ -1,16 +1,18 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (geekpi)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: reviewer: (wxy)
|
||||
[#]: publisher: (wxy)
|
||||
[#]: url: (https://linux.cn/article-12955-1.html)
|
||||
[#]: subject: (Why Vim users will love the Kakoune text editor)
|
||||
[#]: via: (https://opensource.com/article/20/12/kakoune)
|
||||
[#]: author: (Seth Kenlon https://opensource.com/users/seth)
|
||||
|
||||
为什么 Vim 用户会喜欢 Kakoune 文本编辑器？
|
||||
======
|
||||
这个编辑器可能会让人联想到 Vim，但它也提供了很多自己独特的功能和特性。
|
||||
![Typewriter keys in multicolor][1]
|
||||
|
||||
> 这个编辑器可能会让人联想到 Vim，但它也提供了很多自己独特的功能和特性。
|
||||
|
||||
|
||||
|
||||
[Kakoune][2] 文本编辑器的灵感来源于 Vi。它拥有简约的界面、简短的键盘快捷键以及独立的编辑和插入模式，乍一看确实[看起来和感觉很像 Vi][3]。然而，Kakoune 编辑器在设计和功能上都有自己独特的风格，与其说是另一个 Vim，不如说是它是它自己。
|
||||
|
||||
@ -18,80 +20,73 @@
|
||||
|
||||
在 Linux 和 BSD 上，你可以从你的发行版的软件仓库或 port 树上安装 Kakoune。例如，在 Fedora、CentOS 或 RHEL 上：
|
||||
|
||||
|
||||
```
|
||||
`$ sudo dnf install kakoune`
|
||||
$ sudo dnf install kakoune
|
||||
```
|
||||
|
||||
在 Debian、Ubuntu 或类似的系统上：
|
||||
|
||||
|
||||
```
|
||||
`$ sudo apt install kakoune`
|
||||
$ sudo apt install kakoune
|
||||
```
|
||||
|
||||
在 macOS 上，你可以使用 Homebrew：
|
||||
|
||||
|
||||
```
|
||||
`$ brew install kakoune`
|
||||
$ brew install kakoune
|
||||
```
|
||||
|
||||
或者，你也可以[从源码构建][4]。
|
||||
|
||||
启动 Kakoune 的命令是 `kak`。你可以空着启动 Kakoune，也可以在启动时包含文件名让它打开：
|
||||
|
||||
启动 Kakoune 的命令是 `kak`。你可以启动 Kakoune 打开空文件，也可以在启动时包含文件名让它打开：
|
||||
|
||||
```
|
||||
`$ kak example.txt`
|
||||
$ kak example.txt
|
||||
```
|
||||
|
||||
### 使用 Kakoune
|
||||
|
||||
当你启动 Kakoune（不带文件名）时，除了在窗口底部有一个小的状态栏外，它在你的终端中打开的大部分是空的缓冲区。像 Vim 一样，Kakoune 以“正常”模式启动，它把按键作为命令，不向缓冲区输入文本。要进入_插入模式，你必须按 **i**（代表**插入**）或 **a**（代表**追加**）。
|
||||
当你启动 Kakoune（不带文件名）时，除了在窗口底部有一个小的状态栏外，它在你的终端中打开的大部分是空的缓冲区。像 Vim 一样，Kakoune 以“正常”模式启动，它把按键作为命令，不向缓冲区输入文本。要进入*插入模式*，你必须按 `i`（代表<ruby>插入<rt>Insert</rt></ruby>）或 `a`（代表<ruby>追加<rt>Append</rt></ruby>）。
|
||||
|
||||
在插入模式下，Kakoune 的操作和其他编辑器一样。你在键盘上输入，然后你输入的字符就会显示在缓冲区里。在插入模式下，你可以使用方向键来浏览缓冲区。
|
||||
|
||||
### 正常模式
|
||||
|
||||
在正常模式下，你可以发出导航和文本编辑命令。这是从 Vi 传统中借用的最明显的功能。编辑命令包括复制、剪切(在传统的 Unix 编辑术语中，称为 “yank”)、粘贴单词和行、撤销、转换字符大小写等功能。下面是一些基础：
|
||||
|
||||
* **d**：复制并删除当前选择（现代术语中的“剪切”）
|
||||
* **c**：复制并删除当前选择，并进入插入模式
|
||||
* **Esc+Alt+d**：删除当前选择
|
||||
* **y**：复制选择
|
||||
* **p**：粘贴
|
||||
* **<**：取消所选行的缩进
|
||||
* **u**：撤消
|
||||
* **U**：重做
|
||||
* **`**：转为小写
|
||||
* **~**：转换为大写
|
||||
在正常模式下，你可以发出导航和文本编辑命令。这是从 Vi 传统中借用的最明显的功能。编辑命令包括复制、剪切（在传统的 Unix 编辑术语中，称为 “<ruby>猛拉<rt>yank</rt></ruby>”）、粘贴单词和行、撤销、转换字符大小写等功能。下面是一些基础：
|
||||
|
||||
* `d`：复制并删除当前选择（现代术语中的“剪切”）
|
||||
* `c`：复制并删除当前选择，并进入插入模式
|
||||
* `Esc+Alt+d`：删除当前选择
|
||||
* `y`：复制选择
|
||||
* `p`：粘贴
|
||||
* `<`：取消所选行的缩进
|
||||
* `u`：撤消
|
||||
* `U`：重做
|
||||
* `：转为小写
|
||||
* `~`：转换为大写
|
||||
|
||||
### 选择
|
||||
|
||||
在 Kakoune 中，你的光标是一个单字符的移动选择。除非你扩展你的选择，否则任何影响选择的命令都只适用当前光标位置。例如，如果你的光标悬停在字母 **n** 上，那么复制命令（正常模式下的 **c**）会将字母 **n** 复制到剪贴板，而粘贴命令（正常模式下的 **p**）则会将字母 **n** 粘贴到缓冲区。
|
||||
在 Kakoune 中，你的光标是一个单字符的移动选区。除非你扩展你的选区，否则任何影响选区的命令都只适用当前光标位置。例如，如果你的光标悬停在字母 `n` 上，那么复制命令（正常模式下的 `c`）会将字母 `n` 复制到剪贴板，而粘贴命令（正常模式下的 `p`）则会将字母 `n` 粘贴到缓冲区。
|
||||
|
||||
从单个字符扩展选择的最简单方法是进入正常模式，按下 **Shift** 键，同时用方向键移动光标。然而，有几种方法可以根据某些标准来扩展选区。例如，**Alt+l** 将选择区域从光标扩展到当前行的末端。
|
||||
从单个字符扩展选区的最简单方法是进入正常模式，按下 `Shift` 键，同时用方向键移动光标。然而，有几种方法可以根据某些标准来扩展选区。例如，`Alt+l` 将选区从光标扩展到当前行的末端。
|
||||
|
||||
完整的文档可以在 <https://github.com/mawww/kakoune/blob/master/README.asciidoc> 中找到。
|
||||
|
||||
### 函数
|
||||
|
||||
除了这些基本的交互，你还可以执行命令来调用 Kakoune 的内置功能。要访问 Kakoune 的命令行，在普通模式下输入 `:`。在命令行中，你可以执行命令，包括打开文件的 **edit** 命令，保存缓冲区到文件的 **write** 命令，当然还有退出应用的 **quit**。
|
||||
除了这些基本的交互，你还可以执行命令来调用 Kakoune 的内置功能。要访问 Kakoune 的命令行，在普通模式下输入 `:`。在命令行中，你可以执行命令，包括打开文件的 `edit` 命令，保存缓冲区到文件的 `write` 命令，当然还有退出应用的 `quit`。
|
||||
|
||||
还有更多的功能，包括针对特定编程语言和文件格式的特殊选项、使用 [Ranger 文件浏览器][5]浏览文件系统的选项、改变颜色主题、搜索和替换文本等等。
|
||||
还有更多的函数，包括针对特定编程语言和文件格式的特殊选项、使用 [Ranger 文件浏览器][5]浏览文件系统的选项、改变颜色主题、搜索和替换文本等等。
|
||||
|
||||
![Kakoune][6]
|
||||
|
||||
### 尝试 Kakoune
|
||||
|
||||
如果你是一个有经验的 Vim 用户，或者甚至是一个只是略知一二的人，你可能会发现 Kakoune 一开始会让你感到迷惑。它与 Vim 的相似度足以让你陷入一种虚假的熟悉感。一切都与 Vim 一模一样，直到它有了很大的不同。不过，如果你是一个刚接触 Vim 编辑器的新手，或者你是一个正在寻找新挑战的 Vim 用户，那么 Kakoune 可能是你的理想编辑器。
|
||||
如果你是一个有经验的 Vim 用户，或者甚至是一个只是略知一二的人，你可能会发现 Kakoune 一开始会让你感到迷惑。它与 Vim 的相似度足以让你陷入一种虚假的熟悉感。一切都与 Vim 一模一样，直到你发现了完全不同的地方。不过，如果你是一个刚接触 Vim 编辑器的新手，或者你是一个正在寻找新挑战的 Vim 用户，那么 Kakoune 可能是你的理想编辑器。
|
||||
|
||||
你自己试试吧！
|
||||
|
||||
当我刚开始使用 vi 文本编辑器的时候，我很讨厌它。但现在我已经使用 vi 超过17年了。。。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/20/12/kakoune
|
||||
@ -99,7 +94,7 @@ via: https://opensource.com/article/20/12/kakoune
|
||||
作者：[Seth Kenlon][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[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/) 荣誉推出
|
||||
|
||||
@ -107,7 +102,7 @@ via: https://opensource.com/article/20/12/kakoune
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/osdc-docdish-typewriterkeys-3.png?itok=NyBwMdK_ (Typewriter keys in multicolor)
|
||||
[2]: https://kakoune.org/
|
||||
[3]: https://opensource.com/article/20/12/vi-text-editor
|
||||
[3]: https://linux.cn/article-12947-1.html
|
||||
[4]: https://github.com/mawww/kakoune
|
||||
[5]: https://opensource.com/article/20/3/ranger-file-navigator
|
||||
[6]: https://opensource.com/sites/default/files/kakoune-screenshot.png (Kakoune)
|
||||
@ -0,0 +1,80 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (3 critical DevOps concepts we explored in 2020)
|
||||
[#]: via: (https://opensource.com/article/20/12/devops)
|
||||
[#]: author: (Dawn Parzych https://opensource.com/users/dawnparzych)
|
||||
|
||||
3 critical DevOps concepts we explored in 2020
|
||||
======
|
||||
In 2020, Opensource.com's top DevOps articles focused on testing,
|
||||
software methodologies, and the most important part: the people
|
||||
![Looking at a map][1]
|
||||
|
||||
Looking back through Opensource.com's articles about [DevOps][2] in 2020, there was a bit of something for everyone—from people starting the DevOps journey to seasoned DevOps veterans. The articles focused on testing, software methodologies, and DevOps' most important part: the people. Here are the top 10 DevOps articles of 2020.
|
||||
|
||||
### Test-driven development
|
||||
|
||||
Alex Bunardzic shared [many articles about testing][3] this year, and I narrowed the list down to the top three. If you are interested in testing (and I would argue that anybody involved in writing or supporting software should have at least a passing interest in testing), check out these articles.
|
||||
|
||||
In _[How to get started with test-driven development][4]_, Alex uses an analogy to describe the fundamentals of test-driven development (TDD) and explain dependencies and how to eliminate them for testing purposes.
|
||||
|
||||
If you're going to practice TDD, you need to understand how and when to write a unit test. Alex shares his best practices in [_Writing unit test after writing code considered harmful in test-driven development_][5].
|
||||
|
||||
Testing is about determining if code is working as designed, and [_What does it mean for code to "work"?_][6] explores how to define what working code looks like from the perspective of observable behavior.
|
||||
|
||||
### Software methodologies
|
||||
|
||||
People sometimes ask, "How does 'concept x' relate to DevOps?" Both [_DevOps vs. Agile: What's the difference?_][7] by Tonya Brown and [_How does kanban relate to DevOps_][8]_?_ by Willy-Peter Schaub address these questions head-on. Willy explains the four pivotal kanban practices then dives into how they are similar to DevOps. Tonya highlights similarities and differences between DevOps and agile. If you're starting out on your DevOps journey, these articles will help you understand how DevOps is similar to and different from your current practices.
|
||||
|
||||
And speaking of starting out, Sameer S Paradkar's article [_A beginner's guide to everything DevOps_][9] should be bookmarked and shared with anyone new to the practice. He covers everything from how DevOps addresses development and operations challenges, to the differences between traditional IT processes and DevOps, to understanding the DevOps lifecycle. To top it off, Sameer ends with a handy cheat sheet to open source DevOps tools.
|
||||
|
||||
### People
|
||||
|
||||
The people are the most important part of DevOps. They are the ones writing the software, supporting it, building automation, and so much more. Finding the right people is more important than implementing the right tools.
|
||||
|
||||
The right mindset is required to navigate DevOps. In [_10 tips for maintaining a DevOps mindset for distributed teams_][10], Willy-Peter Shaub shares how that mindset helps in the new era of remote work:
|
||||
|
||||
> "A healthy DevOps mindset navigates through different paths of continuous improvement wherein disruption, discipline, and guardrails are the norm. What no one anticipated is the radical disruption we are all experiencing due to the pandemic, and the impact it has on our DevOps and personal mindset, our workflows, and the ceremonies of kanban and agile teams."
|
||||
|
||||
This mindset is crucial as teams evolve how we collaborate, communicate, and deliver software for the remote world.
|
||||
|
||||
Yet, it's not the only thing you need to be successful in DevOps. Josh Atwell shared his list of key skills for DevOps success in [_How to be the right person for DevOps_][11]. It may come as a surprise, but none of the skills are related to programming languages or tools. Being the right person for DevOps requires communication, selflessness, and self-care, Josh says.
|
||||
|
||||
Even the right mindset and attitude won't make everything perfect; there will still be challenges. One of the challenges people face today is burnout. People are getting tired of being remote, and they are looking for things to return to "normal." In [_DevOps is a solution to burnout worth investing in_][12], I discuss how changing underlying processes and cultures can help reduce or prevent burnout.
|
||||
|
||||
Finally, if you're looking for a career change in 2021, consider the role of scrum master. Tonya Brown outlined a day in the life of a scrum master in [_What does a scrum master do?_][13] If you like removing impediments and coaching people on solving problems, this may be a role for you.
|
||||
|
||||
* * *
|
||||
|
||||
What DevOps topics are you interested in reading about? Please share your ideas in the comments, and if you have knowledge to share, please [consider writing about it for Opensource.com][14].
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/20/12/devops
|
||||
|
||||
作者：[Dawn Parzych][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/dawnparzych
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/tips_map_guide_ebook_help_troubleshooting_lightbulb_520.png?itok=L0BQHgjr (Looking at a map)
|
||||
[2]: https://opensource.com/resources/devops
|
||||
[3]: https://opensource.com/users/alex-bunardzic
|
||||
[4]: https://opensource.com/article/20/1/test-driven-development
|
||||
[5]: https://opensource.com/article/20/2/automate-unit-tests
|
||||
[6]: https://opensource.com/article/20/7/code-tdd
|
||||
[7]: https://opensource.com/article/20/2/devops-vs-agile
|
||||
[8]: https://opensource.com/article/20/4/kanban-devops
|
||||
[9]: https://opensource.com/article/20/2/devops-beginners
|
||||
[10]: https://opensource.com/article/20/6/devops-mindset
|
||||
[11]: https://opensource.com/article/20/3/devops-relationships
|
||||
[12]: https://opensource.com/article/20/1/devops-burnout-solution
|
||||
[13]: https://opensource.com/article/20/7/scrum-master
|
||||
[14]: https://opensource.com/how-submit-article
|
||||
131
sources/tech/20201225 How to use heredoc as a text editor.md
Normal file
131
sources/tech/20201225 How to use heredoc as a text editor.md
Normal file
@ -0,0 +1,131 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (How to use heredoc as a text editor)
|
||||
[#]: via: (https://opensource.com/article/20/12/heredoc)
|
||||
[#]: author: (Seth Kenlon https://opensource.com/users/seth)
|
||||
|
||||
How to use heredoc as a text editor
|
||||
======
|
||||
This obscure terminal feature provides a text editor in a pinch.
|
||||
![woman on laptop sitting at the window][1]
|
||||
|
||||
There’s a somewhat obscure feature in Linux and Unix shells that allows you to open a sort of do-while loop for the [cat][2] command. It’s called the _heredoc_, and it enables you to have, more or less, a text editor no matter what shell you’re using. The syntax is:
|
||||
|
||||
|
||||
```
|
||||
`$ cat << EOF >> example.txt`
|
||||
```
|
||||
|
||||
The string in the middle is, essentially, a conditional that stops the loop. That is, if you type alone on a line, the loop ends. During the loop, whatever you type into your terminal is piped into the destination file (in this case).
|
||||
|
||||
### Installing
|
||||
|
||||
As long as you have a terminal, you already have the ability to initiate a heredoc. I’ve used this syntactical trick in [Bash][3], [tsch][4], and Korn shell.
|
||||
|
||||
### Using heredoc
|
||||
|
||||
To open a heredoc "session", you use the cat command with redirection that points first to cat with a terminating string (common convention is **EOF** for "End Of File", but it can actually be anything). After the terminating keyword, you redirect your output to a destination file. You're then able to type directly into your terminal, using most common shell keyboard shortcuts to navigate through your work. Your session ends when you type your designated terminating string on a line by itself. You know you're in a heredoc loop by the unique prompt (usually the **>** character).
|
||||
|
||||
|
||||
```
|
||||
$ cat << EOF >> example.txt
|
||||
> Everything you type here will be placed into example.txt when I type EOF on a line by itself. Until then, you can type...
|
||||
>
|
||||
> whatever...
|
||||
>
|
||||
> you want to type.
|
||||
>
|
||||
> EOF
|
||||
$
|
||||
```
|
||||
|
||||
Everything you enter while your terminal is waiting for **EOF** is placed into the destination file. Prompt characters are omitted, and EOF itself is not part of the file.
|
||||
|
||||
|
||||
```
|
||||
Everything you type here will be placed into example.txt when I type EOF on a line by itself. Until then, you can type...
|
||||
|
||||
whatever...
|
||||
|
||||
you want to type.
|
||||
```
|
||||
|
||||
Realistically, you’re probably not going to use heredoc syntax as a substitute for a good text editor. It's a great quick hack to enter more than one line, but more than 10 lines or so starts to strain its usefulness. For instance, you can’t go up to edit previous lines without triggering your shell’s [history][5] function. Depending on your shell and how it's configured, you may be able to go up, then down to recall your text, and then move back through your text with **Ctrl+B**.
|
||||
|
||||
Most features of your shell work as expected, but there’s probably no undo and very little error recovery.
|
||||
|
||||
And besides, even the most minimal of installs are likely to have at least [Vi][6] or [ed][7] installed.
|
||||
|
||||
And yet heredoc is still useful! It's more flexible than **echo**, and when you’re working on a shell script, it's indispensable. For instance, imagine you’re writing an installer script so you can automate the install of a set of custom applications. One of the applications isn’t distributed with a `.dekstop` file, so it does not appear in your Application menu. To fix this, you decide to generate a `.desktop` file at install time.
|
||||
|
||||
Rather than writing a `.desktop` file and carrying it around as an external dependency for your install script, you could use heredoc in your install script itself:
|
||||
|
||||
|
||||
```
|
||||
#!/bin/sh
|
||||
|
||||
VERSION=${VERSION:-x.y.z}
|
||||
PKGNAM=${VERSION:-example}
|
||||
PKG="${PKGNAM}"-"${VERSION}"-`arch`.tgz
|
||||
|
||||
# download package
|
||||
wget "${PKG}"
|
||||
tar txvf "${PKG}"
|
||||
|
||||
# use here doc to create missing .desktop file
|
||||
cat << EOF >> $HOME/.local/share/applications/example.desktop
|
||||
[Desktop Entry]
|
||||
Version=1.0
|
||||
Type=Application
|
||||
Name="${PKGNAM}"
|
||||
Comment="${PKGNAM}"
|
||||
Exec="${PKGNAM}" %F
|
||||
EOF
|
||||
|
||||
# insert the rest of an install script...
|
||||
```
|
||||
|
||||
You have automated text entry into a file, no text editor involved (except the one you use to write your script, obviously). Here’s what the resulting `.desktop` file looks like:
|
||||
|
||||
|
||||
```
|
||||
[Desktop Entry]
|
||||
Version=1.0
|
||||
Type=Application
|
||||
Name=example
|
||||
Comment=example
|
||||
Exec=example %F
|
||||
```
|
||||
|
||||
As you can see, you can use variables within the heredoc, and they’re correctly resolved. The `EOF` string doesn’t appear in the file; it only signals the end of the heredoc.
|
||||
|
||||
### Better than echo
|
||||
|
||||
The heredoc technique is generally considered easier than `echo` or [printf][8] because once you’re "in" the document, you’re free to do whatever you want. It’s liberating in that sense, but it’s limited compared to a proper text editor.
|
||||
|
||||
Use heredoc for quick notes and for shell scripts, and never puzzle over how to dynamically generate configuration files again.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/20/12/heredoc
|
||||
|
||||
作者：[Seth Kenlon][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/seth
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/lenovo-thinkpad-laptop-window-focus.png?itok=g0xPm2kD (young woman working on a laptop)
|
||||
[2]: https://opensource.com/article/19/2/getting-started-cat-command
|
||||
[3]: https://opensource.com/article/20/4/bash-sysadmins-ebook
|
||||
[4]: https://opensource.com/article/20/8/tcsh
|
||||
[5]: https://opensource.com/article/20/6/bash-history-commands
|
||||
[6]: https://opensource.com/article/19/3/getting-started-vim
|
||||
[7]: https://opensource.com/article/20/12/gnu-ed
|
||||
[8]: https://opensource.com/article/20/8/printf
|
||||
Loading…
Reference in New Issue
Block a user