mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-26 21:30:55 +08:00
Merge remote-tracking branch 'LCTT/master'
This commit is contained in:
Xingyu Wang
commit
ff90ea58d2
@ -0,0 +1,189 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (mengxinayan)
|
||||
[#]: reviewer: (wxy)
|
||||
[#]: publisher: (wxy)
|
||||
[#]: url: (https://linux.cn/article-11935-1.html)
|
||||
[#]: subject: (How to structure a multi-file C program: Part 1)
|
||||
[#]: via: (https://opensource.com/article/19/7/structure-multi-file-c-part-1)
|
||||
[#]: author: (Erik O'Shaughnessy https://opensource.com/users/jnyjnyhttps://opensource.com/users/jnyjnyhttps://opensource.com/users/jim-salterhttps://opensource.com/users/cldxsolutions)
|
||||
|
||||
如何组织构建多文件 C 语言程序（一）
|
||||
======
|
||||
|
||||
> 准备好你喜欢的饮料、编辑器和编译器，放一些音乐，然后开始构建一个由多个文件组成的 C 语言程序。
|
||||
|
||||
|
||||
|
||||
大家常说计算机编程的艺术部分是处理复杂性，部分是命名某些事物。此外，我认为“有时需要添加绘图”是在很大程度上是正确的。
|
||||
|
||||
在这篇文章里，我会编写一个小型 C 程序，命名一些东西，同时处理一些复杂性。该程序的结构大致基于我在 《[如何写一个好的 C 语言 main 函数][2]》 文中讨论的。但是，这次做一些不同的事。准备好你喜欢的饮料、编辑器和编译器，放一些音乐，让我们一起编写一个有趣的 C 语言程序。
|
||||
|
||||
### 优秀 Unix 程序哲学
|
||||
|
||||
首先，你要知道这个 C 程序是一个 [Unix][3] 命令行工具。这意味着它运行在（或者可被移植到）那些提供 Unix C 运行环境的操作系统中。当贝尔实验室发明 Unix 后，它从一开始便充满了[设计哲学][4]。用我自己的话来说就是：程序只做一件事，并做好它，并且对文件进行一些操作。虽然“只做一件事，并做好它”是有意义的，但是“对文件进行一些操作”的部分似乎有点儿不合适。
|
||||
|
||||
事实证明，Unix 中抽象的 “文件” 非常强大。一个 Unix 文件是以文件结束符（EOF）标志为结尾的字节流。仅此而已。文件中任何其它结构均由应用程序所施加而非操作系统。操作系统提供了系统调用，使得程序能够对文件执行一套标准的操作：打开、读取、写入、寻址和关闭（还有其他，但说起来那就复杂了）。对于文件的标准化访问使得不同的程序共用相同的抽象，而且可以一同工作，即使它们是不同的人用不同语言编写的程序。
|
||||
|
||||
具有共享的文件接口使得构建*可组合的*的程序成为可能。一个程序的输出可以作为另一个程序的输入。Unix 家族的操作系统默认在执行程序时提供了三个文件：标准输入（`stdin`）、标准输出（`stdout`）和标准错误（`stderr`）。其中两个文件是只写的：`stdout` 和 `stderr`。而 `stdin` 是只读的。当我们在常见的 Shell 比如 Bash 中使用文件重定向时，可以看到其效果。
|
||||
|
||||
```
|
||||
$ ls | grep foo | sed -e 's/bar/baz/g' > ack
|
||||
```
|
||||
|
||||
这条指令可以被简要地描述为：`ls` 的结果被写入标准输出，它重定向到 `grep` 的标准输入，`grep` 的标准输出重定向到 `sed` 的标准输入，`sed` 的标准输出重定向到当前目录下文件名为 `ack` 的文件中。
|
||||
|
||||
我们希望我们的程序在这个灵活又出色的生态系统中运作良好，因此让我们编写一个可以读写文件的程序。
|
||||
|
||||
### 喵呜喵呜：流编码器/解码器概念
|
||||
|
||||
当我还是一个露着豁牙的孩子懵懵懂懂地学习计算机科学时，学过很多编码方案。它们中的有些用于压缩文件，有些用于打包文件，另一些毫无用处因此显得十分愚蠢。列举最后这种情况的一个例子：[哞哞编码方案][5]。
|
||||
|
||||
为了让我们的程序有个用途，我为它更新了一个 [21 世纪][6] 的概念，并且实现了一个名为“喵呜喵呜” 的编码方案的概念（毕竟网上大家都喜欢猫）。这里的基本的思路是获取文件并且使用文本 “meow” 对每个半字节（半个字节）进行编码。小写字母代表 0，大写字母代表 1。因为它会将 4 个比特替换为 32 个比特，因此会扩大文件的大小。没错，这毫无意义。但是想象一下人们看到经过这样编码后的惊讶表情。
|
||||
|
||||
```
|
||||
$ cat /home/your_sibling/.super_secret_journal_of_my_innermost_thoughts
|
||||
MeOWmeOWmeowMEoW...
|
||||
```
|
||||
|
||||
这非常棒。
|
||||
|
||||
### 最终的实现
|
||||
|
||||
完整的源代码可以在 [GitHub][7] 上面找到，但是我会写下我在编写程序时的思考。目的是说明如何组织构建多文件 C 语言程序。
|
||||
|
||||
既然已经确定了要编写一个编码和解码“喵呜喵呜”格式的文件的程序时，我在 Shell 中执行了以下的命令 ：
|
||||
|
||||
```
|
||||
$ mkdir meowmeow
|
||||
$ cd meowmeow
|
||||
$ git init
|
||||
$ touch Makefile # 编译程序的方法
|
||||
$ touch main.c # 处理命令行选项
|
||||
$ touch main.h # “全局”常量和定义
|
||||
$ touch mmencode.c # 实现对喵呜喵呜文件的编码
|
||||
$ touch mmencode.h # 描述编码 API
|
||||
$ touch mmdecode.c # 实现对喵呜喵呜文件的解码
|
||||
$ touch mmdecode.h # 描述解码 API
|
||||
$ touch table.h # 定义编码查找表
|
||||
$ touch .gitignore # 这个文件中的文件名会被 git 忽略
|
||||
$ git add .
|
||||
$ git commit -m "initial commit of empty files"
|
||||
```
|
||||
|
||||
简单的说，我创建了一个目录，里面全是空文件，并且提交到 git。
|
||||
|
||||
即使这些文件中没有内容，你依旧可以从它的文件名推断每个文件的用途。为了避免万一你无法理解，我在每条 `touch` 命令后面进行了简单描述。
|
||||
|
||||
通常，程序从一个简单 `main.c` 文件开始，只有两三个解决问题的函数。然后程序员轻率地向自己的朋友或者老板展示了该程序，然后为了支持所有新的“功能”和“需求”，文件中的函数数量就迅速爆开了。“程序俱乐部”的第一条规则便是不要谈论“程序俱乐部”，第二条规则是尽量减少单个文件中的函数。
|
||||
|
||||
老实说，C 编译器并不关心程序中的所有函数是否都在一个文件中。但是我们并不是为计算机或编译器写程序，我们是为其他人（有时也包括我们）去写程序的。我知道这可能有些奇怪，但这就是事实。程序体现了计算机解决问题所采用的一组算法，当问题的参数发生了意料之外的变化时，保证人们可以理解它们是非常重要的。当在人们修改程序时，发现一个文件中有 2049 函数时他们会诅咒你的。
|
||||
|
||||
因此，优秀的程序员会将函数分隔开，将相似的函数分组到不同的文件中。这里我用了三个文件 `main.c`、`mmencode.c` 和 `mmdecode.c`。对于这样小的程序，也许看起来有些过头了。但是小的程序很难保证一直小下去，因此哥忒拓展做好计划是一个“好主意”。
|
||||
|
||||
但是那些 `.h` 文件呢？我会在后面解释一般的术语，简单地说，它们被称为头文件，同时它们可以包含 C 语言类型定义和 C 预处理指令。头文件中不应该包含任何函数。你可以认为头文件是提供了应用程序接口（API）的定义的一种 `.c` 文件，可以供其它 `.c` 文件使用。
|
||||
|
||||
### 但是 Makefile 是什么呢？
|
||||
|
||||
我知道下一个轰动一时的应用都是你们这些好孩子们用 “终极代码粉碎者 3000” 集成开发环境来编写的，而构建项目是用 Ctrl-Meta-Shift-Alt-Super-B 等一系列复杂的按键混搭出来的。但是如今（也就是今天），使用 `Makefile` 文件可以在构建 C 程序时帮助做很多有用的工作。`Makefile` 是一个包含如何处理文件的方式的文本文件，程序员可以使用其自动地从源代码构建二进制程序（以及其它东西！）
|
||||
|
||||
以下面这个小东西为例：
|
||||
|
||||
```
|
||||
00 # Makefile
|
||||
01 TARGET= my_sweet_program
|
||||
02 $(TARGET): main.c
|
||||
03 cc -o my_sweet_program main.c
|
||||
```
|
||||
|
||||
`#` 符号后面的文本是注释，例如 00 行。
|
||||
|
||||
01 行是一个变量赋值，将 `TARGET` 变量赋值为字符串 `my_sweet_program`。按照惯例，也是我的习惯，所有 `Makefile` 变量均使用大写字母并用下划线分隔单词。
|
||||
|
||||
02 行包含该<ruby>步骤<rt>recipe</rt></ruby>要创建的文件名和其依赖的文件。在本例中，构建<ruby>目标<rt>target</rt></ruby>是 `my_sweet_program`，其依赖是 `main.c`。
|
||||
|
||||
最后的 03 行使用了一个制表符号（`tab`）而不是四个空格。这是将要执行创建目标的命令。在本例中，我们使用 <ruby>C 编译器<rt>C compiler</rt></ruby>前端 `cc` 以编译链接为 `my_sweet_program`。
|
||||
|
||||
使用 `Makefile` 是非常简单的。
|
||||
|
||||
```
|
||||
$ make
|
||||
cc -o my_sweet_program main.c
|
||||
$ ls
|
||||
Makefile main.c my_sweet_program
|
||||
```
|
||||
|
||||
构建我们喵呜喵呜编码器/解码器的 [Makefile][8] 比上面的例子要复杂，但其基本结构是相同的。我将在另一篇文章中将其分解为 Barney 风格。
|
||||
|
||||
### 形式伴随着功能
|
||||
|
||||
我的想法是程序从一个文件中读取、转换它，并将转换后的结果存储到另一个文件中。以下是我想象使用程序命令行交互时的情况：
|
||||
|
||||
```
|
||||
$ meow < clear.txt > clear.meow
|
||||
$ unmeow < clear.meow > meow.tx
|
||||
$ diff clear.txt meow.tx
|
||||
$
|
||||
```
|
||||
|
||||
我们需要编写代码以进行命令行解析和处理输入/输出流。我们需要一个函数对流进行编码并将结果写到另一个流中。最后，我们需要一个函数对流进行解码并将结果写到另一个流中。等一下，我们在讨论如何写一个程序，但是在上面的例子中，我调用了两个指令：`meow` 和 `unmeow`？我知道你可能会认为这会导致越变越复杂。
|
||||
|
||||
### 次要内容：argv[0] 和 ln 指令
|
||||
|
||||
回想一下，C 语言 main 函数的结构如下：
|
||||
|
||||
```
|
||||
int main(int argc, char *argv[])
|
||||
```
|
||||
|
||||
其中 `argc` 是命令行参数的数量，`argv` 是字符指针（字符串）的列表。`argv[0]` 是包含正在执行的程序的文件路径。在 Unix 系统中许多互补功能的程序（比如：压缩和解压缩）看起来像两个命令，但事实上，它们是在文件系统中拥有两个名称的一个程序。这个技巧是通过使用 `ln` 命令创建文件系统链接来实现两个名称的。
|
||||
|
||||
在我笔记本电脑中 `/usr/bin` 的一个例子如下：
|
||||
|
||||
```
|
||||
$ ls -li /usr/bin/git*
|
||||
3376 -rwxr-xr-x. 113 root root 1.5M Aug 30 2018 /usr/bin/git
|
||||
3376 -rwxr-xr-x. 113 root root 1.5M Aug 30 2018 /usr/bin/git-receive-pack
|
||||
...
|
||||
```
|
||||
|
||||
这里 `git` 和 `git-receive-pack` 是同一个文件但是拥有不同的名字。我们说它们是相同的文件因为它们具有相同的 inode 值（第一列）。inode 是 Unix 文件系统的一个特点，对它的介绍超越了本文的内容范畴。
|
||||
|
||||
优秀或懒惰的程序可以通过 Unix 文件系统的这个特点达到写更少的代码但是交付双倍的程序。首先，我们编写一个基于其 `argv[0]` 的值而作出相应改变的程序，然后我们确保为导致该行为的名称创建链接。
|
||||
|
||||
在我们的 `Makefile` 中，`unmeow` 链接通过以下的方式来创建：
|
||||
|
||||
```
|
||||
# Makefile
|
||||
...
|
||||
$(DECODER): $(ENCODER)
|
||||
$(LN) -f $< $@
|
||||
...
|
||||
```
|
||||
|
||||
我倾向于在 `Makefile` 中将所有内容参数化，很少使用 “裸” 字符串。我将所有的定义都放置在 `Makefile` 文件顶部，以便可以简单地找到并改变它们。当你尝试将程序移植到新的平台上时，需要将 `cc` 改变为某个 `cc` 时，这会很方便。
|
||||
|
||||
除了两个内置变量 `$@` 和 `$<` 之外，该<ruby>步骤<rt>recipe</rt></ruby>看起来相对简单。第一个便是该步骤的目标的快捷方式，在本例中是 `$(DECODER)`（我能记得这个是因为 `@` 符号看起来像是一个目标）。第二个，`$<` 是规则依赖项，在本例中，它解析为 `$(ENCODER)`。
|
||||
|
||||
事情肯定会变得复杂，但它还在管理之中。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/19/7/structure-multi-file-c-part-1
|
||||
|
||||
作者：[Erik O'Shaughnessy][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[萌新阿岩](https://github.com/mengxinayan)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/jnyjnyhttps://opensource.com/users/jnyjnyhttps://opensource.com/users/jim-salterhttps://opensource.com/users/cldxsolutions
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/programming_keyboard_coding.png?itok=E0Vvam7A (Programming keyboard.)
|
||||
[2]: https://linux.cn/article-10949-1.html
|
||||
[3]: https://en.wikipedia.org/wiki/Unix
|
||||
[4]: http://harmful.cat-v.org/cat-v/
|
||||
[5]: http://www.jabberwocky.com/software/moomooencode.html
|
||||
[6]: https://giphy.com/gifs/nyan-cat-sIIhZliB2McAo
|
||||
[7]: https://github.com/JnyJny/meowmeow
|
||||
[8]: https://github.com/JnyJny/meowmeow/blob/master/Makefile
|
||||
@ -0,0 +1,74 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (How we decide when to release Fedora)
|
||||
[#]: via: (https://fedoramagazine.org/how-we-decide-when-to-release-fedora/)
|
||||
[#]: author: (Ben Cotton https://fedoramagazine.org/author/bcotton/)
|
||||
|
||||
How we decide when to release Fedora
|
||||
======
|
||||
|
||||
![][1]
|
||||
|
||||
Open source projects can use a variety of different models for deciding when to put out a release. Some projects release on a set schedule. Others decide on what the next release should contain and release whenever that is ready. Some just wake up one day and decide it’s time to release. And other projects go for a rolling release model, avoiding the question entirely.
|
||||
|
||||
For Fedora, we go with a [schedule-based approach][2]. Releasing twice a year means we can give our contributors time to implement large changes while still keeping on the leading edge. Targeting releases for the end of April and the end of October gives everyone predictability: contributors, users, upstreams, and downstreams.
|
||||
|
||||
But it’s not enough to release whatever’s ready on the scheduled date. We want to make sure that we’re releasing _quality_ software. Over the years, the Fedora community has developed a set of processes to help ensure we can meet both our time and and quality targets.
|
||||
|
||||
### Changes process
|
||||
|
||||
Meeting our goals starts months before the release. Contributors propose changes through our [Changes process][3], which ensures that the community has a chance to provide input and be aware of impacts. For changes with a broad impact (called “system-wide changes”), we require a contingency plan that describes how to back out the change if it’s broken or won’t be ready in time. In addition, the change process includes providing steps for testing. This helps make sure we can properly verify the results of a change.
|
||||
|
||||
Change proposals are due 2-3 months before the beta release date. This gives the community time to evaluate the impact of the change and make adjustments necessary. For example, a new compiler release might require other package maintainers to fix bugs exposed by the new compiler or to make changes that take advantage of new capabilities.
|
||||
|
||||
A few weeks before the beta and final releases, we enter a [code freeze][4]. This ensures a stable target for testing. Bugs identified as blockers and non-blocking bugs that are granted a freeze exception are updated in the repo, but everything else must wait. The freeze lasts until the release.
|
||||
|
||||
### Blocker and freeze exception process
|
||||
|
||||
In a project as large as Fedora, it’s impossible to test every possible combination of packages and configurations. So we have a set of test cases that we run to make sure the key features are covered.
|
||||
|
||||
As much as we’d like to ship with zero bugs, if we waited until we reached that state, there’d never be another Fedora release again. Instead, we’ve defined release criteria that define what bugs can [block the release][5]. We have [basic release criteria][6] that apply to all release milestones, and then separate, cumulative criteria for [beta][7] and [final][8] releases. With beta releases, we’re generally a little more forgiving of rough edges. For a final release, it needs to pass all of beta’s criteria, plus some more that help make it a better user experience.
|
||||
|
||||
The week before a scheduled release, we hold a “[go/no go meeting][9]“. During this meeting, the QA team, release engineering team, and the Fedora Engineering Steering Committee (FESCo) decide whether or not we will ship the release. As part of the decision process, we conduct a final review of blocker bugs. If any accepted blockers remain, we push the release back to a later date.
|
||||
|
||||
Some bugs aren’t severe enough to block the release, but we still would like to get them fixed before the release. This is particularly true of bugs that affect the live image experience. In that case, we grant an [exception for updates that fix those bugs][10].
|
||||
|
||||
### How you can help
|
||||
|
||||
In all my years as a Fedora contributor, I’ve never heard the QA team say “we don’t need any more help.” Contributing to the pre-release testing processes can be a great way to make your first Fedora contribution.
|
||||
|
||||
The Blocker Review meetings happen most Mondays in #fedora-blocker-review on IRC. All members of the Fedora community are welcome to participate in the discussion and voting. One particularly useful contribution is to look at the [proposed blockers][11] and see if you can reproduce them. Knowing if a bug is widespread or not is important to the blocker decision.
|
||||
|
||||
In addition, the QA team conducts test days and test weeks focused on various parts of the distribution: the kernel, GNOME, etc. Test days are announced on [Fedora Magazine][12].
|
||||
|
||||
There are plenty of other ways to contribute to the QA process. The Fedora wiki has a [list of tasks and how to contact the QA team][13]. The Fedora 32 Beta release is a few weeks away, so now’s a great time to get started!
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://fedoramagazine.org/how-we-decide-when-to-release-fedora/
|
||||
|
||||
作者：[Ben Cotton][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://fedoramagazine.org/author/bcotton/
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://fedoramagazine.org/wp-content/uploads/2020/02/releasing-fedora-1-816x345.png
|
||||
[2]: https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Development_Schedule
|
||||
[3]: https://docs.fedoraproject.org/en-US/program_management/changes_policy/
|
||||
[4]: https://fedoraproject.org/wiki/Milestone_freezes
|
||||
[5]: https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
|
||||
[6]: https://fedoraproject.org/wiki/Basic_Release_Criteria
|
||||
[7]: https://fedoraproject.org/wiki/Fedora_32_Beta_Release_Criteria
|
||||
[8]: https://fedoraproject.org/wiki/Fedora_32_Final_Release_Criteria
|
||||
[9]: https://fedoraproject.org/wiki/Go_No_Go_Meeting
|
||||
[10]: https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process
|
||||
[11]: https://qa.fedoraproject.org/blockerbugs/
|
||||
[12]: https://fedoramagazine.org/tag/test-day/
|
||||
[13]: https://fedoraproject.org/wiki/QA/Join
|
||||
@ -1,5 +1,5 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: translator: (caiichenr)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: translator: (geekpi)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
|
||||
@ -1,86 +0,0 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (geekpi)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (How to use byobu to multiplex SSH sessions)
|
||||
[#]: via: (https://opensource.com/article/20/2/byobu-ssh)
|
||||
[#]: author: (Ben Nuttall https://opensource.com/users/bennuttall)
|
||||
|
||||
How to use byobu to multiplex SSH sessions
|
||||
======
|
||||
Byobu allows you to maintain multiple terminal windows, connect via SSH,
|
||||
disconnect, reconnect, and share access, all while keeping the session
|
||||
alive.
|
||||
![Person drinking a hat drink at the computer][1]
|
||||
|
||||
[Byobu][2] is a text-based window manager and terminal multiplexer. It's similar to [GNU Screen][3] but more modern and more intuitive. It also works on most Linux, BSD, and Mac distributions.
|
||||
|
||||
Byobu allows you to maintain multiple terminal windows, connect via SSH (secure shell), disconnect, reconnect, and even let other people access it, all while keeping the session alive.
|
||||
|
||||
For example, if you are SSH'd into a Raspberry Pi or server and run (for example) **sudo apt update && sudo apt upgrade**—and lose your internet connection while it is running, your command will be lost to the void. However, if you start a byobu session first, it will continue running and, when you reconnect, you will find it's been running happily without your eyes on it.
|
||||
|
||||
![The byobu logo is a fun play on screens.][4]
|
||||
|
||||
Byobu is named for a Japanese term for decorative, multi-panel screens that serve as folding room dividers, which I think is quite fitting.
|
||||
|
||||
To install byobu on Debian/Raspbian/Ubuntu:
|
||||
|
||||
**sudo apt install byobu**
|
||||
|
||||
Then enable it:
|
||||
|
||||
**byobu-enable**
|
||||
|
||||
Now drop out of your SSH session and log back in—you'll land in a byobu session. Run a command like **sudo apt update** and close the window (or enter the escape sequence ([**Enter**+**~**+**.**][5]) and log back in. You'll see the update running just as you left it.
|
||||
|
||||
There are a _lot_ of features I don't use regularly or at all. The most common ones I use are:
|
||||
|
||||
* **F2** – New window
|
||||
* **F3/F4** – Navigate between windows
|
||||
* **Ctrl**+**F2** – Split pane vertically
|
||||
* **Shift**+**F2** – Split pane horizontally
|
||||
* **Shift**+**Left arrow/Shift**+**Right arrow** – Navigate between splits
|
||||
* **Shift**+**F11** – Zoom in (or out) on a split
|
||||
|
||||
|
||||
|
||||
You can learn more by watching this video:
|
||||
|
||||
### How we're using byobu
|
||||
|
||||
Byobu has been great for the maintenance of [piwheels][6], the convenient, pre-compiled Python packages for Raspberry Pi. We have a horizontal split showing the piwheels monitor in the top half and the syslog entries scrolled in real time on the bottom half. Then, if we want to do something else, we switch to another window. It's particularly handy when we're investigating something collaboratively, as I can see what my colleague Dave types (and correct his typos) while we chat in IRC.
|
||||
|
||||
I have byobu enabled on my home and work servers, so when I log into either machine, everything is as I left it—multiple jobs running, a window left in a particular directory, running a process as another user, that kind of thing.
|
||||
|
||||
![byobu screenshot][7]
|
||||
|
||||
Byobu is handy for development on Raspberry Pis, too. You can launch it on the desktop, run a command, then SSH in and attach yourself to the session where that command is running. Just note that enabling byobu won't change what the terminal launcher does. Just run **byobu** to launch it.
|
||||
|
||||
* * *
|
||||
|
||||
_This article originally appeared on Ben Nuttall's [Tooling blog][8] and is reused with permission._
|
||||
|
||||
Enter the black raspberry. Rubus occidentalis . It's an ominous name for an ominous fruit: the...
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/20/2/byobu-ssh
|
||||
|
||||
作者：[Ben Nuttall][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/bennuttall
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/coffee_tea_laptop_computer_work_desk.png?itok=D5yMx_Dr (Person drinking a hat drink at the computer)
|
||||
[2]: https://byobu.org/
|
||||
[3]: http://www.gnu.org/software/screen/
|
||||
[4]: https://opensource.com/sites/default/files/uploads/byobu.png (byobu screen)
|
||||
[5]: https://www.google.com/search?client=ubuntu&channel=fs&q=Enter-tilde-dot&ie=utf-8&oe=utf-8
|
||||
[6]: https://opensource.com/article/20/1/piwheels
|
||||
[7]: https://opensource.com/sites/default/files/uploads/byobu-screenshot.png (byobu screenshot)
|
||||
[8]: https://tooling.bennuttall.com/byobu/
|
||||
@ -1,189 +0,0 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (mengxinayan)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (How to structure a multi-file C program: Part 1)
|
||||
[#]: via: (https://opensource.com/article/19/7/structure-multi-file-c-part-1)
|
||||
[#]: author: (Erik O'Shaughnessy https://opensource.com/users/jnyjnyhttps://opensource.com/users/jnyjnyhttps://opensource.com/users/jim-salterhttps://opensource.com/users/cldxsolutions)
|
||||
|
||||
如何组织构建多文件 C 语言程序：第一部分
|
||||
======
|
||||
|
||||
准备好你喜欢的饮料，编辑器和编译器，放一些音乐，然后开始构建一个由多个文件组成的 C 语言程序。
|
||||
![Programming keyboard.][1]
|
||||
|
||||
大家常说计算机编程的艺术是管理复杂性和命名某些事物中的一部分。此外，我认为“有时需要添加绘图”是很正确的。
|
||||
|
||||
在这篇文章里，我会在编写一个小型 C 程序时命名一些东西同时管理一些复杂性。程序的结构基于我所在 “[如何写一个好的 C 语言 main 函数][2]” 文中讨论的。但是，这次做一些不同的事。准备好你喜欢的饮料，编辑器和编译器，放一些音乐，让我们一起编写一个有趣的 C 语言程序。
|
||||
|
||||
### 好的 Unix 程序中的哲学
|
||||
|
||||
首先你要知道这个 C 程序是一个 [Unix][3] 命令行工具。这意味着它运行在那些提供（或者可被移植） Unix C 运行环境的操作系统中。当 Unix 在贝尔实验室被发明后，它从一开始便充满了 [设计哲学][4]。用我的话来说：程序只做一件事，并做好它，然后对文件进行一些操作。虽然只做一件事并做好它是有意义的，但是“对文件进行一些操作”在这儿有一点儿不合适。
|
||||
|
||||
“文件” 在 Unix 中的抽象非常强大。一个 Unix 文件是以 end-of-file (EOF) 标志为结尾的字节流。文件中其他结构均由应用添加而非操作系统。操作系统提供了系统调用，使得程序能够对文件执行标准操作：打开，读取，写入，寻找和关闭（还有其他，但那是庞大的额外内容）。对于文件的标准化访问使得不同人用不同语言编写的程序能共用相同的抽象同时一起工作。
|
||||
|
||||
具有共享文件接口可以构建 _可组合的_ 的程序。一个程序的输出可以作为另一个程序的输入。Unix 系操作系统默认为每个运行中程序提供了三个文件：标准输入（`stdin`），标准输出（`stdout`），和标准错误（`stderr`）。其中两个文件是只写的：`stdout` 和 `stderr`。而 `stdin` 是只读的。当我们在常见的 Shell 比如 Bash 中使用文件重定向时，可以看到其效果。
|
||||
|
||||
```
|
||||
`$ ls | grep foo | sed -e 's/bar/baz/g' > ack`
|
||||
```
|
||||
|
||||
这条指令可以被简要地描述为：`ls` 的结果被写入标准输出，它重定向到 `grep` 的标准输入，`grep` 的标准输出重定向到 `sed`的标准输入，`sed` 的标准输出重定向到当前目录下文件名为 `ack` 的文件中。
|
||||
|
||||
我们希望我们的程序在系统中灵活而又出色，因此让我们编写一个可以读写文件的程序。
|
||||
|
||||
### MeowMeow: 流编码器/解码器概念
|
||||
|
||||
当我还是一个孩子在 ltmumblesgts 里学习计算机科学时，有许多编码方案。他们中的有些用于压缩文件，有些用于打包文件，另一些毫无用处因此显得十分愚蠢。列举一个最后一种情况例子：[MooMoo 编码方式][5]。
|
||||
|
||||
为了给我们程序一个目的，我将在 [2000s][6] 更新该概念并且完成一个名为 “MeowMeow” 的编码方式（因为在互联网上大家都喜欢猫）。这里的基本的想法获取文件并且使用文本 “meow” 对每半个字节进行编码。小写字母代表 0，大写字母代表 1。因为它会将 4 比特替换为 32 比特，因此会扩大文件的大小。这毫无实际意义。但想象一下人们看到经过这样编码后的结果。
|
||||
|
||||
```
|
||||
$ cat /home/your_sibling/.super_secret_journal_of_my_innermost_thoughts
|
||||
MeOWmeOWmeowMEoW...
|
||||
```
|
||||
|
||||
这非常棒。
|
||||
|
||||
### 最后完成
|
||||
|
||||
完整的源代码可以在 [GitHub][7] 上面找到，但是我会写下我在编写程序时的思考。目的是说明如何组织构建多文件 C 语言程序。
|
||||
|
||||
当我已经确定要编写一个 MeowMeow 编码和解码的程序时，我在 Shell 中执行了以下的命令 ：
|
||||
|
||||
```
|
||||
$ mkdir meowmeow
|
||||
$ cd meowmeow
|
||||
$ git init
|
||||
$ touch Makefile # recipes for compiling the program
|
||||
$ touch main.c # handles command-line options
|
||||
$ touch main.h # "global" constants and definitions
|
||||
$ touch mmencode.c # implements encoding a MeowMeow file
|
||||
$ touch mmencode.h # describes the encoding API
|
||||
$ touch mmdecode.c # implements decoding a MeowMeow file
|
||||
$ touch mmdecode.h # describes the decoding API
|
||||
$ touch table.h # defines encoding lookup table values
|
||||
$ touch .gitignore # names in this file are ignored by git
|
||||
$ git add .
|
||||
$ git commit -m "initial commit of empty files"
|
||||
```
|
||||
|
||||
简单的说，我创建了一个空文件并且使用 git 提交。
|
||||
In short, I created a directory full of empty files and committed them to git.
|
||||
|
||||
即使文件中没有内容，你依旧可以从它的文件名推断功能。为了避免万一你无法理解，我在每条 `touch` 命令后面进行了简单描述。
|
||||
|
||||
通常，一个程序从一个简单 `main.c` 文件开始，只需要两三个函数便可以解决问题。然后程序员便可以向自己的朋友或者老板展示该程序，同时突然显示了文件提示框支持所有新的“功能”和“需求”。“程序俱乐部”的第一条规则便是不谈论“程序俱乐部”。第二条规则是最小化单个文件的功能。
|
||||
|
||||
坦率地说，C 编译器并不关心程序中的所有函数是否都在一个文件中。但是我们并不是为计算机或编译器写程序，我们是为其他人（有时也包括我们）而去写程序的。我知道这有些奇怪，但这就是事实。程序是计算机解决问题所采用的一系列算法，保证人们可以理解它们是非常重要的，即使问题的参数发生了意料之外的变化。当在人们修改程序时，发现一个文件中有 2049 函数时会诅咒你的。
|
||||
|
||||
因此，好的程序员会将函数分隔开，将相似的函数分组到不同的文件中。这里我用了三个文件 `main.c`，`mmencode.c` 和 `mmdecode.c`。对于这样的小程序，也许看起来有些过头了。但是小程序很难保证一直小下去，因此计划拓展是一个好主意。
|
||||
|
||||
但是那些 `.h` 文件呢？我会在后面解释一般的术语，简单地说，它们被称为头文件，同时它们可以包含 C 语言类型 和 C 预处理指令。头文件中不应该包含任何函数。你可以认为头文件和对应 `.c` 文件提供了用户编程接口（API）的定义，以便其他 `.c` 文件使用。
|
||||
|
||||
### 但是 Makefile 是什么呢？
|
||||
|
||||
我知道所有的酷小孩都使用 “Ultra CodeShredder 3000” 集成开发环境来编写下一个轰动一时的应用，同时构建你的项目包括在 Ctrl-Meta-Shift-Alt-Super-B 上进行混搭。但是回到今天，使用 Makefile 文件可以帮助做很多有用的工作在构建 C 程序时。Makefile 是一个包含如何处理文件的方式的文本文件，程序员可以使用其自动地从源代码构建二进制程序（包括其他东西！）
|
||||
|
||||
以下面这个小程序为例：
|
||||
|
||||
```
|
||||
00 # Makefile
|
||||
01 TARGET= my_sweet_program
|
||||
02 $(TARGET): main.c
|
||||
03 cc -o my_sweet_program main.c
|
||||
```
|
||||
|
||||
‘#’ 符号后面的文本是注释，例如 00 行
|
||||
|
||||
01 行是一个变量赋值，将 `TARGET` 变量赋值为字符串 `my_sweet_program`。按照惯例我的习惯是，所有 Makefile 变量均使用大写字母并用下划线分隔单词。
|
||||
|
||||
02 行包含要创建的文件名和其依赖的文件。在本例中，构建目标是 `my_sweet_program`，其依赖是 `main.c`。
|
||||
|
||||
03 行是最后一行使用了一个制表符号（tab）而不是四个空格。这是将执行创建目标的命令。在本例中，我们使用 C 编译器前端 `cc` 以编译链接到 `my_sweet_program`。
|
||||
|
||||
使用 Makefile 是非常简单的。
|
||||
|
||||
```
|
||||
$ make
|
||||
cc -o my_sweet_program main.c
|
||||
$ ls
|
||||
Makefile main.c my_sweet_program
|
||||
```
|
||||
|
||||
将构建我们 MeowMeow 编码和解码器的 [Makefile][8] 比上面的例子要复杂，但其基本结构是相同的。我将在另一篇文章中将其分解为 Barney 风格。
|
||||
|
||||
### 形式伴随着功能
|
||||
|
||||
我的想法是程序从一个文件中读取，转换它，并将转换后的结果存储到另一个文件中。以下是我想象使用程序命令行交互时的情况：
|
||||
|
||||
```
|
||||
$ meow < clear.txt > clear.meow
|
||||
$ unmeow < clear.meow > meow.tx
|
||||
$ diff clear.txt meow.tx
|
||||
$
|
||||
```
|
||||
|
||||
我们需要编写命令行解析和处理输入/输出流的代码。我们需要一个函数对流进行编码并将结果写到另一个流中。最后，我们需要一个函数对流进行解码并将结果写到另一个流中。等一下，我们在讨论如何写一个程序，但是在上面的例子中，我调用了两个指令：`meow` 和 `unmeow`？我知道你可能会认为这会导致越变越复杂。
|
||||
|
||||
### 次要内容：argv[0] 和 ln 指令
|
||||
|
||||
回想一下，C 语言 main 函数的结构如下：
|
||||
|
||||
```
|
||||
`int main(int argc, char *argv[])`
|
||||
```
|
||||
|
||||
其中 `argc` 是命令行参数数量，`argv` 是字符指针列表（字符串）。`argv[0]` 是正在运行中的文件的路径。在 Unix 系统中许多互补功能的程序（比如：压缩和解压缩）看起来像两个命令，但事实上，它们在文件系统中是拥有两个名称的一个程序。使用 `ln` 命令通过创建文件系统链接来实现两个名称的功能。
|
||||
|
||||
一个在我笔记本中 `/usr/bin` 的例子如下：
|
||||
|
||||
```
|
||||
$ ls -li /usr/bin/git*
|
||||
3376 -rwxr-xr-x. 113 root root 1.5M Aug 30 2018 /usr/bin/git
|
||||
3376 -rwxr-xr-x. 113 root root 1.5M Aug 30 2018 /usr/bin/git-receive-pack
|
||||
...
|
||||
```
|
||||
|
||||
这里 `git` 和 `git-receive-pack` 是同一个文件但是拥有不同的名字。我们说它们是相同的文件因为它们具有相同的 inode 值（第一列）。inode 是一个 Unix 文件系统的特点，其超越了本文的内容。
|
||||
|
||||
优秀或懒惰的程序可以通过 Unix 文件系统此特点已达到写更少的代码但是交付双倍的程序。首先，我们编写一个基于其 `argv[0]` 的值而作出相应改变的程序，然后我们确保为该行为的名称创建链接。
|
||||
|
||||
在我们的 Makefile 中，`unmeow` 链接通过以下的方式来创建：
|
||||
|
||||
```
|
||||
# Makefile
|
||||
...
|
||||
$(DECODER): $(ENCODER)
|
||||
$(LN) -f $< $@
|
||||
...
|
||||
```
|
||||
|
||||
我喜欢在 Makefile 中将所有内容参数化，很少使用 “裸” 字符串。我将所有的定义都放置在 Makefile 文件顶部，以便可以简单地找到并改变它们。当您尝试将程序移植到新的平台上时，需要将 `cc` 改变为 `xcc`时，这会产生很大影响。
|
||||
|
||||
除了两个内置变量 `$@` 和 `$<` 之外，其余的变量显得很简单的。第一个便是创建目标的快捷方式，在本例中，`$(DECODER)` （我记忆它因为它看起来像一个目标）。第二个，`$<` 是规则依赖项，在本例中，它解析为 `$(ENCODER)`。
|
||||
|
||||
事情当然在变得复杂，但是它易于管理。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/19/7/structure-multi-file-c-part-1
|
||||
|
||||
作者：[Erik O'Shaughnessy][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[萌新阿岩](https://github.com/mengxinayan)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/jnyjnyhttps://opensource.com/users/jnyjnyhttps://opensource.com/users/jim-salterhttps://opensource.com/users/cldxsolutions
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/programming_keyboard_coding.png?itok=E0Vvam7A (Programming keyboard.)
|
||||
[2]: https://opensource.com/article/19/5/how-write-good-c-main-function
|
||||
[3]: https://en.wikipedia.org/wiki/Unix
|
||||
[4]: http://harmful.cat-v.org/cat-v/
|
||||
[5]: http://www.jabberwocky.com/software/moomooencode.html
|
||||
[6]: https://giphy.com/gifs/nyan-cat-sIIhZliB2McAo
|
||||
[7]: https://github.com/JnyJny/meowmeow
|
||||
[8]: https://github.com/JnyJny/meowmeow/blob/master/Makefile
|
||||
@ -0,0 +1,79 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (geekpi)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (How to use byobu to multiplex SSH sessions)
|
||||
[#]: via: (https://opensource.com/article/20/2/byobu-ssh)
|
||||
[#]: author: (Ben Nuttall https://opensource.com/users/bennuttall)
|
||||
|
||||
如何使用 byobu 复用 SSH 会话
|
||||
======
|
||||
Byobu 能让你在保持会话活跃的情况下维护多个终端窗口、通过 SSH 连接、断开、重连以及共享访问。
|
||||
![Person drinking a hat drink at the computer][1]
|
||||
|
||||
[Byobu][2] 是基于文本的窗口管理器和终端多路复用器。它类似于 [GNU Screen][3]，但更现代，更直观。它还适用于大多数 Linux、BSD 和 Mac 发行版。
|
||||
|
||||
Byobu 能让你在保持会话活跃的情况下维护多个终端窗口、通过 SSH （secure shell）连接、断开、重连，甚至让其他人访问。
|
||||
|
||||
比如，你 SSH 进入树莓派或服务器，并运行（比如） **sudo apt update && sudo apt upgrade**，然后你在它运行的时候失去了互联网连接，你的命令会丢失无效。然而，如果你首先启动 byobu 会话，那么它会继续运行，在你重连后，你会发现它仍在继续运行。
|
||||
|
||||
![The byobu logo is a fun play on screens.][4]
|
||||
|
||||
Byobu 的日语术语是指装饰性多面板屏风，可作为折叠式隔断，我认为这很合适。
|
||||
|
||||
要在 Debian/Raspbian/Ubuntu 上安装 byobu：
|
||||
|
||||
**sudo apt install byobu**
|
||||
|
||||
接着启用它
|
||||
|
||||
**byobu-enable**
|
||||
|
||||
现在，请退出 SSH 会话并重新登录，你将会在 byobu 会话中登录。运行类似 **sudo apt update** 命令并关闭窗口（或输入转义序列（[**Enter**+**~**+**.**][5]）并重新登录。你将看到更新在你离开后还在运行。
|
||||
|
||||
有_很多_我不常使用的功能。我通常使用的是：
|
||||
|
||||
* **F2** – 新窗口
|
||||
* **F3/F4** – 在窗口间导航
|
||||
* **Ctrl**+**F2** – 垂直拆分窗格
|
||||
* **Shift**+**F2** – 水平拆分窗格
|
||||
* **Shift**+**左箭头/Shift**+**右箭头** – 在拆分窗格间导航
|
||||
* **Shift**+**F11** – 放大（或缩小）拆分窗格
|
||||
|
||||
|
||||
### 我们如何使用 byobu
|
||||
|
||||
Byobu 对于 [piwheels][6]（一个用于树莓派的方便的，预编译 Python 包）的维护很方便。我门水平拆分了窗格，在上半部分显示了 piwheels 监视器，在下半部分实时显示了 syslog 条目。接着，如果我们想要做其他事情，我们可以切换到另外一个窗口。当我们进行协作调查时，这特别方便，因为当我在 IRC 中聊天时，我可以看到我的同事 Dave 输入了什么（并纠正他的错字）。
|
||||
|
||||
我在家庭和办公服务器上启用了 byobu，因此，当我登录到任何一台计算机时，一切都与我离开时一样。它正在运行多个作业、在特定目录中保留一个窗口，以另一个用户身份运行进程等。
|
||||
|
||||
![byobu screenshot][7]
|
||||
|
||||
Byobu 也很方便用于在树莓派上进行开发。你可以在桌面上启动它，运行命令，然后 SSH 进入，并连接到该命令运行所在的会话。请注意，启用 byobu 不会更改终端启动器的功能。只需运行 **byobu** 即可启动它。
|
||||
|
||||
* * *
|
||||
|
||||
_本文最初发表在 Ben Nuttall 的 [Tooling blog][8] 中，并获许重用_
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/20/2/byobu-ssh
|
||||
|
||||
作者：[Ben Nuttall][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[geekpi](https://github.com/geekpi)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/bennuttall
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/coffee_tea_laptop_computer_work_desk.png?itok=D5yMx_Dr (Person drinking a hat drink at the computer)
|
||||
[2]: https://byobu.org/
|
||||
[3]: http://www.gnu.org/software/screen/
|
||||
[4]: https://opensource.com/sites/default/files/uploads/byobu.png (byobu screen)
|
||||
[5]: https://www.google.com/search?client=ubuntu&channel=fs&q=Enter-tilde-dot&ie=utf-8&oe=utf-8
|
||||
[6]: https://opensource.com/article/20/1/piwheels
|
||||
[7]: https://opensource.com/sites/default/files/uploads/byobu-screenshot.png (byobu screenshot)
|
||||
[8]: https://tooling.bennuttall.com/byobu/
|
||||
Loading…
Reference in New Issue
Block a user