mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-01-25 23:11:02 +08:00
Merge remote-tracking branch 'LCTT/master'
This commit is contained in:
Xingyu.Wang
commit
7547991550
@ -1,24 +1,25 @@
|
||||
如何创建和维护你的Man手册
|
||||
如何创建和维护你自己的 man 手册
|
||||
======
|
||||
|
||||
|
||||
|
||||
我们已经讨论了一些[Man手册的替代方案] [1]。 这些替代方案主要用于学习简洁的Linux命令示例，而无需通过全面过于详细的手册页。 如果你正在寻找一种快速而简单的方法来轻松快速地学习Linux命令，那么这些替代方案值得尝试。 现在，你可能正在考虑 - 如何为Linux命令创建自己的man-like帮助页面？ 这时**“Um”**就派上用场了。 Um是一个命令行实用程序，用于轻松创建和维护包含你到目前为止所了解的所有命令的Man页面。
|
||||
我们已经讨论了一些 [man 手册的替代方案][1]。 这些替代方案主要用于学习简洁的 Linux 命令示例，而无需通过全面而过于详细的手册页。 如果你正在寻找一种快速而简单的方法来轻松快速地学习 Linux 命令，那么这些替代方案值得尝试。 现在，你可能正在考虑 —— 如何为 Linux 命令创建自己的 man 式的帮助页面？ 这时 “Um” 就派上用场了。 Um 是一个命令行实用程序，可以用于轻松创建和维护包含你到目前为止所了解的所有命令的 man 页面。
|
||||
|
||||
通过创建自己的手册页，你可以在手册页中避免大量不必要的细节，并且只包含你需要记住的内容。 如果你想创建自己的一套man-like页面，“Um”也能为你提供帮助。 在这个简短的教程中，我们将学习如何安装“Um”命令以及如何创建自己的man手册页。
|
||||
通过创建自己的手册页，你可以在手册页中避免大量不必要的细节，并且只包含你需要记住的内容。 如果你想创建自己的一套 man 式的页面，“Um” 也能为你提供帮助。 在这个简短的教程中，我们将学习如何安装 “Um” 命令以及如何创建自己的 man 手册页。
|
||||
|
||||
### 安装 Um
|
||||
|
||||
Um适用于Linux和Mac OS。 目前，它只能在Linux系统中使用** Linuxbrew **软件包管理器来进行安装。 如果你尚未安装Linuxbrew，请参考以下链接。
|
||||
Um 适用于 Linux 和Mac OS。 目前，它只能在 Linux 系统中使用 Linuxbrew 软件包管理器来进行安装。 如果你尚未安装 Linuxbrew，请参考以下链接：
|
||||
|
||||
安装Linuxbrew后，运行以下命令安装Um实用程序。
|
||||
- [Linuxbrew：一个用于 Linux 和 MacOS 的通用包管理器][3]
|
||||
|
||||
安装 Linuxbrew 后，运行以下命令安装 Um 实用程序。
|
||||
|
||||
```
|
||||
$ brew install sinclairtarget/wst/um
|
||||
|
||||
```
|
||||
|
||||
如果你会看到类似下面的输出，恭喜你！ Um已经安装好并且可以使用了。
|
||||
如果你会看到类似下面的输出，恭喜你！ Um 已经安装好并且可以使用了。
|
||||
|
||||
```
|
||||
[...]
|
||||
@ -49,88 +50,78 @@ Emacs Lisp files have been installed to:
|
||||
==> um
|
||||
Bash completion has been installed to:
|
||||
/home/linuxbrew/.linuxbrew/etc/bash_completion.d
|
||||
|
||||
```
|
||||
|
||||
在制作你的man手册页之前，你需要为Um启用bash补全。
|
||||
在制作你的 man 手册页之前，你需要为 Um 启用 bash 补全。
|
||||
|
||||
要开启bash'补全，首先你需要打开 **~/.bash_profile** 文件:
|
||||
要开启 bash 补全，首先你需要打开 `~/.bash_profile` 文件:
|
||||
|
||||
```
|
||||
$ nano ~/.bash_profile
|
||||
|
||||
```
|
||||
|
||||
并在其中添加以下内容:
|
||||
并在其中添加以下内容：
|
||||
|
||||
```
|
||||
if [ -f $(brew --prefix)/etc/bash_completion.d/um-completion.sh ]; then
|
||||
. $(brew --prefix)/etc/bash_completion.d/um-completion.sh
|
||||
fi
|
||||
|
||||
```
|
||||
|
||||
保存并关闭文件。运行以下命令以更新更改。
|
||||
|
||||
```
|
||||
$ source ~/.bash_profile
|
||||
|
||||
```
|
||||
|
||||
准备工作全部完成。让我们继续创建我们的第一个man手册页。
|
||||
准备工作全部完成。让我们继续创建我们的第一个 man 手册页。
|
||||
|
||||
### 创建并维护自己的man手册
|
||||
|
||||
### 创建并维护自己的Man手册
|
||||
|
||||
如果你想为“dpkg”命令创建自己的Man手册。请运行:
|
||||
如果你想为 `dpkg` 命令创建自己的 man 手册。请运行:
|
||||
|
||||
```
|
||||
$ um edit dpkg
|
||||
|
||||
```
|
||||
|
||||
上面的命令将在默认编辑器中打开markdown模板：
|
||||
上面的命令将在默认编辑器中打开 markdown 模板：
|
||||
|
||||
|
||||
|
||||
我的默认编辑器是Vi，因此上面的命令会在Vi编辑器中打开它。现在，开始在此模板中添加有关“dpkg”命令的所有内容。
|
||||
我的默认编辑器是 Vi，因此上面的命令会在 Vi 编辑器中打开它。现在，开始在此模板中添加有关 `dpkg` 命令的所有内容。
|
||||
|
||||
下面是一个示例:
|
||||
下面是一个示例：
|
||||
|
||||
|
||||
|
||||
正如你在上图的输出中看到的，我为dpkg命令添加了概要，描述和两个参数选项。 你可以在Man手册中添加你所需要的所有部分。不过你也要确保为每个部分提供了适当且易于理解的标题。 完成后，保存并退出文件（如果使用Vi编辑器，请按ESC键并键入：wq）。
|
||||
正如你在上图的输出中看到的，我为 `dpkg` 命令添加了概要，描述和两个参数选项。 你可以在 man 手册中添加你所需要的所有部分。不过你也要确保为每个部分提供了适当且易于理解的标题。 完成后，保存并退出文件（如果使用 Vi 编辑器，请按 `ESC` 键并键入`:wq`）。
|
||||
|
||||
最后，使用以下命令查看新创建的Man手册页：
|
||||
最后，使用以下命令查看新创建的 man 手册页：
|
||||
|
||||
```
|
||||
$ um dpkg
|
||||
|
||||
```
|
||||
|
||||
|
||||
|
||||
如你所见，dpkg的Man手册页看起来与官方手册页完全相同。 如果要在手册页中编辑和/或添加更多详细信息，请再次运行相同的命令并添加更多详细信息。
|
||||
如你所见，`dpkg` 的 man 手册页看起来与官方手册页完全相同。 如果要在手册页中编辑和/或添加更多详细信息，请再次运行相同的命令并添加更多详细信息。
|
||||
|
||||
```
|
||||
$ um edit dpkg
|
||||
|
||||
```
|
||||
|
||||
要使用Um查看新创建的Man手册页列表，请运行：
|
||||
要使用 Um 查看新创建的 man 手册页列表，请运行：
|
||||
|
||||
```
|
||||
$ um list
|
||||
|
||||
```
|
||||
|
||||
所有手册页将保存在主目录中名为**`.um` **的目录下
|
||||
所有手册页将保存在主目录中名为 `.um` 的目录下
|
||||
|
||||
以防万一，如果你不想要某个特定页面，只需删除它，如下所示。
|
||||
|
||||
```
|
||||
$ um rm dpkg
|
||||
|
||||
```
|
||||
|
||||
要查看帮助部分和所有可用的常规选项，请运行：
|
||||
@ -151,7 +142,6 @@ Subcommands:
|
||||
um topics List all topics.
|
||||
um (c)onfig [config key] Display configuration environment.
|
||||
um (h)elp [sub-command] Display this help message, or the help message for a sub-command.
|
||||
|
||||
```
|
||||
|
||||
### 配置 Um
|
||||
@ -166,22 +156,18 @@ pager = less
|
||||
pages_directory = /home/sk/.um/pages
|
||||
default_topic = shell
|
||||
pages_ext = .md
|
||||
|
||||
```
|
||||
|
||||
在此文件中，你可以根据需要编辑和更改** pager **，** editor **，** default_topic **，** pages_directory **和** pages_ext **选项的值。 比如说，如果你想在** [Dropbox] [2] **文件夹中保存新创建的Um页面，只需更改/.um/umconfig**文件中** pages_directory **的值并将其更改为Dropbox文件夹即可。
|
||||
在此文件中，你可以根据需要编辑和更改 `pager`、`editor`、`default_topic`、`pages_directory` 和 `pages_ext` 选项的值。 比如说，如果你想在 [Dropbox][2] 文件夹中保存新创建的 Um 页面，只需更改 `~/.um/umconfig` 文件中 `pages_directory` 的值并将其更改为 Dropbox 文件夹即可。
|
||||
|
||||
```
|
||||
pages_directory = /Users/myusername/Dropbox/um
|
||||
|
||||
```
|
||||
|
||||
这就是全部内容，希望这些能对你有用，更多好的内容敬请关注！
|
||||
|
||||
干杯！
|
||||
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.ostechnix.com/how-to-create-and-maintain-your-own-man-pages/
|
||||
@ -189,7 +175,7 @@ via: https://www.ostechnix.com/how-to-create-and-maintain-your-own-man-pages/
|
||||
作者：[SK][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[way-ww](https://github.com/way-ww)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
@ -197,3 +183,4 @@ via: https://www.ostechnix.com/how-to-create-and-maintain-your-own-man-pages/
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://www.ostechnix.com/3-good-alternatives-man-pages-every-linux-user-know/
|
||||
[2]: https://www.ostechnix.com/install-dropbox-in-ubuntu-18-04-lts-desktop/
|
||||
[3]: https://www.ostechnix.com/linuxbrew-common-package-manager-linux-mac-os-x/
|
||||
@ -1,3 +1,5 @@
|
||||
translating by ypingcn
|
||||
|
||||
Creator of the World Wide Web is Creating a New Decentralized Web
|
||||
======
|
||||
**Creator of the world wide web, Tim Berners-Lee has unveiled his plans to create a new decentralized web where the data will be controlled by the users.**
|
||||
|
||||
@ -0,0 +1,64 @@
|
||||
We already have nice things, and other reasons not to write in-house ops tools
|
||||
======
|
||||
Let's look at the pitfalls of writing in-house ops tools, the circumstances that justify it, and how to do it better.
|
||||
|
||||
|
||||
When I was an ops consultant, I had the "great fortune" of seeing the dark underbelly of many companies in a relatively short period of time. Such fortune was exceptionally pronounced on one client engagement where I became the maintainer of an in-house deployment tool that had bloated to touch nearly every piece of infrastructure—despite lacking documentation and testing. Dismayed at the impossible task of maintaining this beast while tackling the real work of improving the product, I began reviewing my old client projects and probing my ops community for their strategies. What I found was an epidemic of "[not invented here][1]" (NIH) syndrome and a lack of collaboration with the broader community.
|
||||
|
||||
### The problem with NIH
|
||||
|
||||
One of the biggest problems of NIH is the time suck for engineers. Instead of working on functionality that adds value to the business, they're adding features to tools that solve standard problems such as deployment, continuous integration (CI), and configuration management.
|
||||
|
||||
This is a serious issue at small or midsized startups, where new hires need to hit the ground running. If they have to learn a completely new toolset, rather than drawing from their experience with industry-standard tools, the time it takes them to become useful increases dramatically. While the new hires are learning the in-house tools, the company remains reliant on the handful of people who wrote the tools to document, train, and troubleshoot them. Heaven forbid one of those engineers succumbs to [the bus factor][2], because the possibility of getting outside help if they forgot to document something is zero.
|
||||
|
||||
### Do you need to roll it yourself?
|
||||
|
||||
Before writing your own ops tool, ask yourself the following questions:
|
||||
|
||||
* Have we polled the greater ops community for solutions?
|
||||
* Have we compared the costs of proprietary tools to the estimated engineering time needed to maintain an in-house solution?
|
||||
* Have we identified open source solutions, even those that lack desired features, and attempted to contribute to them?
|
||||
* Can we fork any open source tools that are well-written but unmaintained?
|
||||
|
||||
|
||||
|
||||
If you still can't find a tool that meets your needs, you'll have to roll your own.
|
||||
|
||||
### Tips for rolling your own
|
||||
|
||||
Here's a checklist for rolling your own solutions:
|
||||
|
||||
1. In-house tooling should not be exempt from the high standards you apply to the rest of your code. Write it like you're going to open source it.
|
||||
2. Make sure you allow time in your sprints to work on feature requests, and don't allow features to be rushed in before proper testing and documentation.
|
||||
3. Keep it small. It's going to be much harder to exact any kind of exit strategy if your tool is a monstrosity that touches everything.
|
||||
4. Track your tool's usage and prune features that aren't actively utilized.
|
||||
|
||||
|
||||
|
||||
### Have an exit strategy
|
||||
|
||||
Open sourcing your in-house tool is not an exit strategy per se, but it may help you get outside contributors to free up your engineers' time. This is the more difficult strategy and will take some extra care and planning. Read "[Starting an Open Source Project][3]" and "[So You've Decided To Open-Source A Project At Work. What Now?][4]" before committing to this path. If you're interested in a cleaner exit, set aside time each quarter to research and test new open source replacements.
|
||||
|
||||
Regardless of which path you choose, explicitly stating that an in-house solution is not the preferred state—early in its development—should clear up any confusion and prevent the issue of changing directions from becoming political.
|
||||
|
||||
Sabice Arkenvirr will present [We Already Have Nice Things, Use Them!][5] at [LISA18][6], October 29-31 in Nashville, Tennessee, USA.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/18/10/nice-things
|
||||
|
||||
作者：[Sabice Arkenvirr][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/vishuzdelishuz
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://en.wikipedia.org/wiki/Not_invented_here
|
||||
[2]: https://en.wikipedia.org/wiki/Bus_factor
|
||||
[3]: https://opensource.guide/starting-a-project/
|
||||
[4]: https://www.smashingmagazine.com/2013/12/open-sourcing-projects-guide-getting-started/
|
||||
[5]: https://www.usenix.org/conference/lisa18/presentation/arkenvirr
|
||||
[6]: https://www.usenix.org/conference/lisa18
|
||||
@ -0,0 +1,93 @@
|
||||
Think global: How to overcome cultural communication challenges
|
||||
======
|
||||
Use these tips to ensure that every member of your global development team feels involved and understood.
|
||||
|
||||
|
||||
A few weeks ago, I witnessed an interesting interaction between two work colleagues—Jason, who is from the United States; and Raj, who was visiting from India.
|
||||
|
||||
Raj typically calls into a daily standup meeting at 9:00am US Central Time from India, but since he was in the US, he and his teammates headed toward the scrum area for the meeting. Jason stopped Raj and said, “Raj, where are you going? Don’t you always call into the stand-up? It would feel strange if you don’t call in.” Raj responded, “Oh, is that so? No worries,” and headed back to his desk to call into the meeting.
|
||||
|
||||
I went to Raj’s desk. “Hey, Raj, why aren’t you going to the daily standup?” Raj replied, “Jason asked me to call in.” Meanwhile, Jason was waiting for Raj to come to the standup.
|
||||
|
||||
What happened here? Jason was obviously joking when he made the remark about Raj calling into the meeting. But how did Raj miss this?
|
||||
|
||||
Jason’s statement was meant as a joke, but Raj took it literally. This was a clear example of a misunderstanding that occurred due to unfamiliarity with each other’s cultural context.
|
||||
|
||||
I often encounter emails that end with “Please revert back to me.” At first, this phrase left me puzzled. I thought, "What changes do they want me to revert?" Finally, I figured out that “please revert” means “Please reply.”
|
||||
|
||||
In his TED talk, “[Managing Cross Cultural Remote Teams,][1]” Ricardo Fernandez describes an interaction with a South African colleague who ended an IM conversation with “I’ll call you just now.” Ricardo went back to his office and waited for the call. After fifteen minutes, he called his colleague: “Weren’t you going to call me just now?” The colleague responded, “Yes, I was going to call you just now.” That's when Ricardo realized that to his South African colleague, the phrase “just now” meant “sometime in the future.”
|
||||
|
||||
In today's workplace, our colleagues may not be located in the same office, city, or even country. A growing number of tech companies have a global workforce comprised of employees with varied experiences and perspectives. This diversity allows companies to compete in the rapidly evolving technological environment.
|
||||
|
||||
But geographically dispersed teams can face challenges. Managing and maintaining high-performing development teams is difficult even when the members are co-located; when team members come from different backgrounds and locations, that makes it even harder. Communication can deteriorate, misunderstandings can happen, and teams may stop trusting each other—all of which can affect the success of the company.
|
||||
|
||||
What factors can cause confusion in global communication? In her book, “[The Culture Map][2],” Erin Meyer presents eight scales into which all global cultures fit. We can use these scales to improve our relationships with international colleagues. She identifies the United States as a very low-context culture in the communication scale. In contrast, Japan is identified as a high-context culture.
|
||||
|
||||
What does it mean to be a high- or low-context culture? In the United States, children learn to communicate explicitly: “Say what you mean; mean what you say” is a common principle of communication. On the other hand, Japanese children learn to communicate effectively by mastering the ability to “read the air.” That means they are able to read between the lines and pick up on social cues when communicating.
|
||||
|
||||
Most Asian cultures follow the high-context style of communication. Not surprisingly, the United States, a young country composed of immigrants, follows a low-context culture: Since the people who immigrated to the United States came from different cultural backgrounds, they had no choice but to communicate explicitly and directly.
|
||||
|
||||
### The three R’s
|
||||
|
||||
How can we overcome challenges in cross-cultural communication? Americans communicating with Japanese colleagues, for example, should pay attention to the non-verbal cues, while Japanese communicating with Americans should prepare for more direct language. If you are facing a similar challenge, follow these three steps to communicate more effectively and improve relationships with your international colleagues.
|
||||
|
||||
#### Recognize the differences in cultural context
|
||||
|
||||
The first step toward effective cross-cultural communication is to recognize that there are differences. Start by increasing your awareness of other cultures.
|
||||
|
||||
#### Respect the differences in cultural context
|
||||
|
||||
Once you become aware that differences in cultural context can affect cross-cultural communication, the next step is to respect these differences. When you notice a different style of communication, learn to embrace the difference and actively listen to the other person’s point of view.
|
||||
|
||||
#### Reconcile the differences in cultural context
|
||||
|
||||
Merely recognizing and respecting cultural differences is not enough; you must also learn how to reconcile the cultural differences. Understanding and being empathetic towards the other culture will help you reconcile the differences and learn how to use them to better advance productivity.
|
||||
|
||||
### 5 ways to improve communications for cultural context
|
||||
|
||||
Over the years, I have incorporated various approaches, tips, and tricks to strengthen relationships among team members across the globe. These approaches have helped me overcome communication challenges with global colleagues. Here are a few examples:
|
||||
|
||||
#### Always use video conferencing when communicating with global teammates
|
||||
|
||||
Studies show that about 55% of communication is non-verbal. Body language offers many subtle cues that can help you decipher messages, and video conferencing enables geographically dispersed team members to see each other. Videoconferencing is my default choice when conducting remote meetings.
|
||||
|
||||
#### Ensure that every team member gets an opportunity to share their thoughts and ideas
|
||||
|
||||
Although I prefer to conduct meetings using video conferencing, this is not always possible. If video conferencing is not a common practice at your workplace, it might take some effort to get everyone comfortable with the concept. Start by encouraging everyone to participate in audio meetings.
|
||||
|
||||
One of our remote team members, who frequently met with us in audio conferences, mentioned that she often wanted to share ideas and contribute to the meeting but since we couldn’t see her and she couldn’t see us, she had no idea when to start speaking. If you are using audio conferencing, one way to mitigate this is to ensure that every team member gets an opportunity to share their ideas.
|
||||
|
||||
#### Learn from one another
|
||||
|
||||
Leverage your international friends to learn about their cultural context. This will help you interact more effectively with colleagues from these countries. I have friends from South Asia and South America who have helped me better understand their cultures, and this knowledge has helped me professionally.
|
||||
|
||||
For programmers, I recommend conducting code reviews with your global peers. This will help you understand how those from different cultures give and receive feedback, persuade others, and make technical decisions.
|
||||
|
||||
#### Be empathetic
|
||||
|
||||
Empathy is the key to strong relationships. The more you are able to put yourself in someone else's shoes, the better able you will be to gain trust and build long-lasting connections. Encourage “water-cooler” conversations among your global colleagues by allocating the first few minutes of each meeting for small talk. This offers the additional benefit of putting everyone in a more relaxed mindset. If you manage a global team, make sure every member feels included in the discussion.
|
||||
|
||||
#### Meet your global colleagues in person
|
||||
|
||||
The best way to build long-lasting relationships is to meet your team members in person. If your company can afford it, arrange for this to happen. Meeting colleagues with whom you have been working will likely strengthen your relationship with them. The companies I have worked for have a strong record of periodically sending US team members to other countries and global colleagues to the US office.
|
||||
|
||||
Another way to bring teams together is to attend conferences. This not only creates educational and training opportunities, but you can also carve out some in-person team time.
|
||||
|
||||
In today's increasingly global economy, it is becoming more important for companies to maintain a geographically diverse workforce to remain competitive. Although global teams can face communication challenges, it is possible to maintain a high-performing development team despite geographical and cultural differences. Share some of the techniques you use in the comments.
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/18/10/think-global-communication-challenges
|
||||
|
||||
作者：[Avindra Fernando][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/avindrafernando
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://www.youtube.com/watch?v=QIoAkFpN8wQ
|
||||
[2]: https://www.amazon.com/The-Culture-Map-Invisible-Boundaries/dp/1610392507
|
||||
File diff suppressed because it is too large
Load Diff
@ -1,397 +0,0 @@
|
||||
translating by Flowsnow
|
||||
|
||||
How to build rpm packages
|
||||
======
|
||||
|
||||
Save time and effort installing files and scripts across multiple hosts.
|
||||
|
||||
|
||||
|
||||
I have used rpm-based package managers to install software on Red Hat and Fedora Linux since I started using Linux more than 20 years ago. I have used the **rpm** program itself, **yum** , and **DNF** , which is a close descendant of yum, to install and update packages on my Linux hosts. The yum and DNF tools are wrappers around the rpm utility that provide additional functionality, such as the ability to find and install package dependencies.
|
||||
|
||||
Over the years I have created a number of Bash scripts, some of which have separate configuration files, that I like to install on most of my new computers and virtual machines. It reached the point that it took a great deal of time to install all of these packages, so I decided to automate that process by creating an rpm package that I could copy to the target hosts and install all of these files in their proper locations. Although the **rpm** tool was formerly used to build rpm packages, that function was removed and a new tool,was created to build new rpms.
|
||||
|
||||
When I started this project, I found very little information about creating rpm packages, but I managed to find a book, Maximum RPM, that helped me figure it out. That book is now somewhat out of date, as is the vast majority of information I have found. It is also out of print, and used copies go for hundreds of dollars. The online version of [Maximum RPM][1] is available at no charge and is kept up to date. The [RPM website][2] also has links to other websites that have a lot of documentation about rpm. What other information there is tends to be brief and apparently assumes that you already have a good deal of knowledge about the process.
|
||||
|
||||
In addition, every one of the documents I found assumes that the code needs to be compiled from sources as in a development environment. I am not a developer. I am a sysadmin, and we sysadmins have different needs because we don’t—or we shouldn’t—compile code to use for administrative tasks; we should use shell scripts. So we have no source code in the sense that it is something that needs to be compiled into binary executables. What we have is a source that is also the executable.
|
||||
|
||||
For the most part, this project should be performed as the non-root user student. Rpms should never be built by root, but only by non-privileged users. I will indicate which parts should be performed as root and which by a non-root, unprivileged user.
|
||||
|
||||
### Preparation
|
||||
|
||||
First, open one terminal session and `su` to root. Be sure to use the `-` option to ensure that the complete root environment is enabled. I do not believe that sysadmins should use `sudo` for any administrative tasks. Find out why in my personal blog post: [Real SysAdmins don’t sudo][3].
|
||||
|
||||
```
|
||||
[student@testvm1 ~]$ su -
|
||||
Password:
|
||||
[root@testvm1 ~]#
|
||||
```
|
||||
|
||||
Create a student user that can be used for this project and set a password for that user.
|
||||
|
||||
```
|
||||
[root@testvm1 ~]# useradd -c "Student User" student
|
||||
[root@testvm1 ~]# passwd student
|
||||
Changing password for user student.
|
||||
New password: <Enter the password>
|
||||
Retype new password: <Enter the password>
|
||||
passwd: all authentication tokens updated successfully.
|
||||
[root@testvm1 ~]#
|
||||
```
|
||||
|
||||
Building rpm packages requires the `rpm-build` package, which is likely not already installed. Install it now as root. Note that this command will also install several dependencies. The number may vary, depending upon the packages already installed on your host; it installed a total of 17 packages on my test VM, which is pretty minimal.
|
||||
|
||||
```
|
||||
dnf install -y rpm-build
|
||||
```
|
||||
|
||||
The rest of this project should be performed as the user student unless otherwise explicitly directed. Open another terminal session and use `su` to switch to that user to perform the rest of these steps. Download a tarball that I have prepared of a development directory structure, utils.tar, from GitHub using the following command:
|
||||
|
||||
```
|
||||
wget https://github.com/opensourceway/how-to-rpm/raw/master/utils.tar
|
||||
```
|
||||
|
||||
This tarball includes all of the files and Bash scripts that will be installed by the final rpm. There is also a complete spec file, which you can use to build the rpm. We will go into detail about each section of the spec file.
|
||||
|
||||
As user student, using your home directory as your present working directory (pwd), untar the tarball.
|
||||
|
||||
```
|
||||
[student@testvm1 ~]$ cd ; tar -xvf utils.tar
|
||||
```
|
||||
|
||||
Use the `tree` command to verify that the directory structure of ~/development and the contained files looks like the following output:
|
||||
|
||||
```
|
||||
[student@testvm1 ~]$ tree development/
|
||||
development/
|
||||
├── license
|
||||
│ ├── Copyright.and.GPL.Notice.txt
|
||||
│ └── GPL_LICENSE.txt
|
||||
├── scripts
|
||||
│ ├── create_motd
|
||||
│ ├── die
|
||||
│ ├── mymotd
|
||||
│ └── sysdata
|
||||
└── spec
|
||||
└── utils.spec
|
||||
|
||||
3 directories, 7 files
|
||||
[student@testvm1 ~]$
|
||||
```
|
||||
|
||||
The `mymotd` script creates a “Message Of The Day” data stream that is sent to stdout. The `create_motd` script runs the `mymotd` scripts and redirects the output to the /etc/motd file. This file is used to display a daily message to users who log in remotely using SSH.
|
||||
|
||||
The `die` script is my own script that wraps the `kill` command in a bit of code that can find running programs that match a specified string and kill them. It uses `kill -9` to ensure that they cannot ignore the kill message.
|
||||
|
||||
The `sysdata` script can spew tens of thousands of lines of data about your computer hardware, the installed version of Linux, all installed packages, and the metadata of your hard drives. I use it to document the state of a host at a point in time. I can later use it for reference. I used to do this to maintain a record of hosts that I installed for customers.
|
||||
|
||||
You may need to change ownership of these files and directories to student.student. Do this, if necessary, using the following command:
|
||||
|
||||
```
|
||||
chown -R student.student development
|
||||
```
|
||||
|
||||
Most of the files and directories in this tree will be installed on Fedora systems by the rpm you create during this project.
|
||||
|
||||
### Creating the build directory structure
|
||||
|
||||
The `rpmbuild` command requires a very specific directory structure. You must create this directory structure yourself because no automated way is provided. Create the following directory structure in your home directory:
|
||||
|
||||
```
|
||||
~ ─ rpmbuild
|
||||
├── RPMS
|
||||
│ └── noarch
|
||||
├── SOURCES
|
||||
├── SPECS
|
||||
└── SRPMS
|
||||
```
|
||||
|
||||
We will not create the rpmbuild/RPMS/X86_64 directory because that would be architecture-specific for 64-bit compiled binaries. We have shell scripts that are not architecture-specific. In reality, we won’t be using the SRPMS directory either, which would contain source files for the compiler.
|
||||
|
||||
### Examining the spec file
|
||||
|
||||
Each spec file has a number of sections, some of which may be ignored or omitted, depending upon the specific circumstances of the rpm build. This particular spec file is not an example of a minimal file required to work, but it is a good example of a moderately complex spec file that packages files that do not need to be compiled. If a compile were required, it would be performed in the `%build` section, which is omitted from this spec file because it is not required.
|
||||
|
||||
#### Preamble
|
||||
|
||||
This is the only section of the spec file that does not have a label. It consists of much of the information you see when the command `rpm -qi [Package Name]` is run. Each datum is a single line which consists of a tag, which identifies it and text data for the value of the tag.
|
||||
|
||||
```
|
||||
###############################################################################
|
||||
# Spec file for utils
|
||||
################################################################################
|
||||
# Configured to be built by user student or other non-root user
|
||||
################################################################################
|
||||
#
|
||||
Summary: Utility scripts for testing RPM creation
|
||||
Name: utils
|
||||
Version: 1.0.0
|
||||
Release: 1
|
||||
License: GPL
|
||||
URL: http://www.both.org
|
||||
Group: System
|
||||
Packager: David Both
|
||||
Requires: bash
|
||||
Requires: screen
|
||||
Requires: mc
|
||||
Requires: dmidecode
|
||||
BuildRoot: ~/rpmbuild/
|
||||
|
||||
# Build with the following syntax:
|
||||
# rpmbuild --target noarch -bb utils.spec
|
||||
```
|
||||
|
||||
Comment lines are ignored by the `rpmbuild` program. I always like to add a comment to this section that contains the exact syntax of the `rpmbuild` command required to create the package. The Summary tag is a short description of the package. The Name, Version, and Release tags are used to create the name of the rpm file, as in utils-1.00-1.rpm. Incrementing the release and version numbers lets you create rpms that can be used to update older ones.
|
||||
|
||||
The License tag defines the license under which the package is released. I always use a variation of the GPL. Specifying the license is important to clarify the fact that the software contained in the package is open source. This is also why I included the license and GPL statement in the files that will be installed.
|
||||
|
||||
The URL is usually the web page of the project or project owner. In this case, it is my personal web page.
|
||||
|
||||
The Group tag is interesting and is usually used for GUI applications. The value of the Group tag determines which group of icons in the applications menu will contain the icon for the executable in this package. Used in conjunction with the Icon tag (which we are not using here), the Group tag allows adding the icon and the required information to launch a program into the applications menu structure.
|
||||
|
||||
The Packager tag is used to specify the person or organization responsible for maintaining and creating the package.
|
||||
|
||||
The Requires statements define the dependencies for this rpm. Each is a package name. If one of the specified packages is not present, the DNF installation utility will try to locate it in one of the defined repositories defined in /etc/yum.repos.d and install it if it exists. If DNF cannot find one or more of the required packages, it will throw an error indicating which packages are missing and terminate.
|
||||
|
||||
The BuildRoot line specifies the top-level directory in which the `rpmbuild` tool will find the spec file and in which it will create temporary directories while it builds the package. The finished package will be stored in the noarch subdirectory that we specified earlier. The comment showing the command syntax used to build this package includes the option `–target noarch`, which defines the target architecture. Because these are Bash scripts, they are not associated with a specific CPU architecture. If this option were omitted, the build would be targeted to the architecture of the CPU on which the build is being performed.
|
||||
|
||||
The `rpmbuild` program can target many different architectures, and using the `--target` option allows us to build architecture-specific packages on a host with a different architecture from the one on which the build is performed. So I could build a package intended for use on an i686 architecture on an x86_64 host, and vice versa.
|
||||
|
||||
Change the packager name to yours and the URL to your own website if you have one.
|
||||
|
||||
#### %description
|
||||
|
||||
The `%description` section of the spec file contains a description of the rpm package. It can be very short or can contain many lines of information. Our `%description` section is rather terse.
|
||||
|
||||
```
|
||||
%description
|
||||
A collection of utility scripts for testing RPM creation.
|
||||
```
|
||||
|
||||
#### %prep
|
||||
|
||||
The `%prep` section is the first script that is executed during the build process. This script is not executed during the installation of the package.
|
||||
|
||||
This script is just a Bash shell script. It prepares the build directory, creating directories used for the build as required and copying the appropriate files into their respective directories. This would include the sources required for a complete compile as part of the build.
|
||||
|
||||
The $RPM_BUILD_ROOT directory represents the root directory of an installed system. The directories created in the $RPM_BUILD_ROOT directory are fully qualified paths, such as /user/local/share/utils, /usr/local/bin, and so on, in a live filesystem.
|
||||
|
||||
In the case of our package, we have no pre-compile sources as all of our programs are Bash scripts. So we simply copy those scripts and other files into the directories where they belong in the installed system.
|
||||
|
||||
```
|
||||
%prep
|
||||
################################################################################
|
||||
# Create the build tree and copy the files from the development directories #
|
||||
# into the build tree. #
|
||||
################################################################################
|
||||
echo "BUILDROOT = $RPM_BUILD_ROOT"
|
||||
mkdir -p $RPM_BUILD_ROOT/usr/local/bin/
|
||||
mkdir -p $RPM_BUILD_ROOT/usr/local/share/utils
|
||||
|
||||
cp /home/student/development/utils/scripts/* $RPM_BUILD_ROOT/usr/local/bin
|
||||
cp /home/student/development/utils/license/* $RPM_BUILD_ROOT/usr/local/share/utils
|
||||
cp /home/student/development/utils/spec/* $RPM_BUILD_ROOT/usr/local/share/utils
|
||||
|
||||
exit
|
||||
```
|
||||
|
||||
Note that the exit statement at the end of this section is required.
|
||||
|
||||
#### %files
|
||||
|
||||
This section of the spec file defines the files to be installed and their locations in the directory tree. It also specifies the file attributes and the owner and group owner for each file to be installed. The file permissions and ownerships are optional, but I recommend that they be explicitly set to eliminate any chance for those attributes to be incorrect or ambiguous when installed. Directories are created as required during the installation if they do not already exist.
|
||||
|
||||
```
|
||||
%files
|
||||
%attr(0744, root, root) /usr/local/bin/*
|
||||
%attr(0644, root, root) /usr/local/share/utils/*
|
||||
```
|
||||
|
||||
#### %pre
|
||||
|
||||
This section is empty in our lab project’s spec file. This would be the place to put any scripts that are required to run during installation of the rpm but prior to the installation of the files.
|
||||
|
||||
#### %post
|
||||
|
||||
This section of the spec file is another Bash script. This one runs after the installation of files. This section can be pretty much anything you need or want it to be, including creating files, running system commands, and restarting services to reinitialize them after making configuration changes. The `%post` script for our rpm package performs some of those tasks.
|
||||
|
||||
```
|
||||
%post
|
||||
################################################################################
|
||||
# Set up MOTD scripts #
|
||||
################################################################################
|
||||
cd /etc
|
||||
# Save the old MOTD if it exists
|
||||
if [ -e motd ]
|
||||
then
|
||||
cp motd motd.orig
|
||||
fi
|
||||
# If not there already, Add link to create_motd to cron.daily
|
||||
cd /etc/cron.daily
|
||||
if [ ! -e create_motd ]
|
||||
then
|
||||
ln -s /usr/local/bin/create_motd
|
||||
fi
|
||||
# create the MOTD for the first time
|
||||
/usr/local/bin/mymotd > /etc/motd
|
||||
```
|
||||
|
||||
The comments included in this script should make its purpose clear.
|
||||
|
||||
#### %postun
|
||||
|
||||
This section contains a script that would be run after the rpm package is uninstalled. Using rpm or DNF to remove a package removes all of the files listed in the `%files` section, but it does not remove files or links created by the `%post` section, so we need to handle that in this section.
|
||||
|
||||
This script usually consists of cleanup tasks that simply erasing the files previously installed by the rpm cannot accomplish. In the case of our package, it includes removing the link created by the `%post` script and restoring the saved original of the motd file.
|
||||
|
||||
```
|
||||
%postun
|
||||
# remove installed files and links
|
||||
rm /etc/cron.daily/create_motd
|
||||
|
||||
# Restore the original MOTD if it was backed up
|
||||
if [ -e /etc/motd.orig ]
|
||||
then
|
||||
mv -f /etc/motd.orig /etc/motd
|
||||
fi
|
||||
```
|
||||
|
||||
#### %clean
|
||||
|
||||
This Bash script performs cleanup after the rpm build process. The two lines in the `%clean` section below remove the build directories created by the `rpm-build` command. In many cases, additional cleanup may also be required.
|
||||
|
||||
```
|
||||
%clean
|
||||
rm -rf $RPM_BUILD_ROOT/usr/local/bin
|
||||
rm -rf $RPM_BUILD_ROOT/usr/local/share/utils
|
||||
```
|
||||
|
||||
#### %changelog
|
||||
|
||||
This optional text section contains a list of changes to the rpm and files it contains. The newest changes are recorded at the top of this section.
|
||||
|
||||
```
|
||||
%changelog
|
||||
* Wed Aug 29 2018 Your Name <Youremail@yourdomain.com>
|
||||
- The original package includes several useful scripts. it is
|
||||
primarily intended to be used to illustrate the process of
|
||||
building an RPM.
|
||||
```
|
||||
|
||||
Replace the data in the header line with your own name and email address.
|
||||
|
||||
### Building the rpm
|
||||
|
||||
The spec file must be in the SPECS directory of the rpmbuild tree. I find it easiest to create a link to the actual spec file in that directory so that it can be edited in the development directory and there is no need to copy it to the SPECS directory. Make the SPECS directory your pwd, then create the link.
|
||||
|
||||
```
|
||||
cd ~/rpmbuild/SPECS/
|
||||
ln -s ~/development/spec/utils.spec
|
||||
```
|
||||
|
||||
Run the following command to build the rpm. It should only take a moment to create the rpm if no errors occur.
|
||||
|
||||
```
|
||||
rpmbuild --target noarch -bb utils.spec
|
||||
```
|
||||
|
||||
Check in the ~/rpmbuild/RPMS/noarch directory to verify that the new rpm exists there.
|
||||
|
||||
```
|
||||
[student@testvm1 ~]$ cd rpmbuild/RPMS/noarch/
|
||||
[student@testvm1 noarch]$ ll
|
||||
total 24
|
||||
-rw-rw-r--. 1 student student 24364 Aug 30 10:00 utils-1.0.0-1.noarch.rpm
|
||||
[student@testvm1 noarch]$
|
||||
```
|
||||
|
||||
### Testing the rpm
|
||||
|
||||
As root, install the rpm to verify that it installs correctly and that the files are installed in the correct directories. The exact name of the rpm will depend upon the values you used for the tags in the Preamble section, but if you used the ones in the sample, the rpm name will be as shown in the sample command below:
|
||||
|
||||
```
|
||||
[root@testvm1 ~]# cd /home/student/rpmbuild/RPMS/noarch/
|
||||
[root@testvm1 noarch]# ll
|
||||
total 24
|
||||
-rw-rw-r--. 1 student student 24364 Aug 30 10:00 utils-1.0.0-1.noarch.rpm
|
||||
[root@testvm1 noarch]# rpm -ivh utils-1.0.0-1.noarch.rpm
|
||||
Preparing... ################################# [100%]
|
||||
Updating / installing...
|
||||
1:utils-1.0.0-1 ################################# [100%]
|
||||
```
|
||||
|
||||
Check /usr/local/bin to ensure that the new files are there. You should also verify that the create_motd link in /etc/cron.daily has been created.
|
||||
|
||||
Use the `rpm -q --changelog utils` command to view the changelog. View the files installed by the package using the `rpm -ql utils` command (that is a lowercase L in `ql`.)
|
||||
|
||||
```
|
||||
[root@testvm1 noarch]# rpm -q --changelog utils
|
||||
* Wed Aug 29 2018 Your Name <Youremail@yourdomain.com>
|
||||
- The original package includes several useful scripts. it is
|
||||
primarily intended to be used to illustrate the process of
|
||||
building an RPM.
|
||||
|
||||
[root@testvm1 noarch]# rpm -ql utils
|
||||
/usr/local/bin/create_motd
|
||||
/usr/local/bin/die
|
||||
/usr/local/bin/mymotd
|
||||
/usr/local/bin/sysdata
|
||||
/usr/local/share/utils/Copyright.and.GPL.Notice.txt
|
||||
/usr/local/share/utils/GPL_LICENSE.txt
|
||||
/usr/local/share/utils/utils.spec
|
||||
[root@testvm1 noarch]#
|
||||
```
|
||||
|
||||
Remove the package.
|
||||
|
||||
```
|
||||
rpm -e utils
|
||||
```
|
||||
|
||||
### Experimenting
|
||||
|
||||
Now you will change the spec file to require a package that does not exist. This will simulate a dependency that cannot be met. Add the following line immediately under the existing Requires line:
|
||||
|
||||
```
|
||||
Requires: badrequire
|
||||
```
|
||||
|
||||
Build the package and attempt to install it. What message is displayed?
|
||||
|
||||
We used the `rpm` command to install and delete the `utils` package. Try installing the package with yum or DNF. You must be in the same directory as the package or specify the full path to the package for this to work.
|
||||
|
||||
### Conclusion
|
||||
|
||||
There are many tags and a couple sections that we did not cover in this look at the basics of creating an rpm package. The resources listed below can provide more information. Building rpm packages is not difficult; you just need the right information. I hope this helps you—it took me months to figure things out on my own.
|
||||
|
||||
We did not cover building from source code, but if you are a developer, that should be a simple step from this point.
|
||||
|
||||
Creating rpm packages is another good way to be a lazy sysadmin and save time and effort. It provides an easy method for distributing and installing the scripts and other files that we as sysadmins need to install on many hosts.
|
||||
|
||||
### Resources
|
||||
|
||||
* Edward C. Baily, Maximum RPM, Sams Publishing, 2000, ISBN 0-672-31105-4
|
||||
|
||||
* Edward C. Baily, [Maximum RPM][1], updated online version
|
||||
|
||||
* [RPM Documentation][4]: This web page lists most of the available online documentation for rpm. It includes many links to other websites and information about rpm.
|
||||
|
||||
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/18/9/how-build-rpm-packages
|
||||
|
||||
作者：[David Both][a]
|
||||
选题：[lujun9972](https://github.com/lujun9972)
|
||||
译者：[译者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/dboth
|
||||
[1]: http://ftp.rpm.org/max-rpm/
|
||||
[2]: http://rpm.org/index.html
|
||||
[3]: http://www.both.org/?p=960
|
||||
[4]: http://rpm.org/documentation.html
|
||||
@ -1,3 +1,4 @@
|
||||
Translating by qhwdw
|
||||
Lab 3: User Environments
|
||||
======
|
||||
### Lab 3: User Environments
|
||||
|
||||
@ -1,76 +0,0 @@
|
||||
translating---geekpi
|
||||
|
||||
How to Install GRUB on Arch Linux (UEFI)
|
||||
======
|
||||
|
||||
|
||||
|
||||
Some time ago, I wrote a tutorial on **[how to reinstall Grub][1] on Arch Linux after installing Windows.**
|
||||
|
||||
A few weeks ago, I had to reinstall **Arch Linux** from scratch on my laptop and I discovered installing **Grub** was not as straightforward as I remembered.
|
||||
|
||||
For this reason, I’m going to write this tutorial since **installing Grub on a UEFI bios** during a new **Arch Linux** installation it’s not too easy.
|
||||
|
||||
### Locating the EFI partition
|
||||
|
||||
The first important thing to do for installing **Grub** on **Arch Linux** is to locate the **EFI** partition.
|
||||
Let’s run the following command in order to locate this partition:
|
||||
|
||||
```
|
||||
# fdisk -l
|
||||
```
|
||||
|
||||
We need to check the partition marked as **EFI System
|
||||
**In my case is **/dev/sda2**
|
||||
|
||||
After that, we need to mount this partition, for example, on /boot/efi:
|
||||
|
||||
```
|
||||
# mkdir /boot/efi
|
||||
# mount /dev/sdb2 /boot/efi
|
||||
```
|
||||
|
||||
Another important thing to do is adding this partition into the **/etc/fstab** file.
|
||||
|
||||
#### Installing Grub
|
||||
|
||||
Now we can install Grub in our system:
|
||||
|
||||
```
|
||||
# grub-mkconfig -o /boot/grub/grub.cfg
|
||||
# grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=GRUB
|
||||
```
|
||||
|
||||
#### Adding Windows Automatically into the Grub Menu
|
||||
|
||||
In order to automatically add the **Windows entry into the Grub menu** , we need to install the **os-prober** program:
|
||||
|
||||
```
|
||||
# pacman -Sy os-prober
|
||||
```
|
||||
|
||||
In order to add the entry item let’s run the following commands:
|
||||
|
||||
```
|
||||
# os-prober
|
||||
# grub-mkconfig -o /boot/grub/grub.cfg
|
||||
# grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=GRUB
|
||||
```
|
||||
|
||||
You can find more about Grub on Arch Linux [here][2].
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://fasterland.net/how-to-install-grub-on-arch-linux-uefi.html
|
||||
|
||||
作者：[Francesco Mondello][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: http://fasterland.net/
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: http://fasterland.net/reinstall-grub-arch-linux.html
|
||||
[2]: https://wiki.archlinux.org/index.php/GRUB
|
||||
@ -1,151 +0,0 @@
|
||||
How To Browse And Read Entire Arch Wiki As Linux Man Pages
|
||||
======
|
||||
|
||||
|
||||
A while ago, I wrote a guide that described how to browse the Arch Wiki from your Terminal using a command line script named [**arch-wiki-cli**][1]. Using this script, anyone can easily navigate through entire Arch Wiki website and read it with a text browser of your choice. Obviously, an active Internet connection is required to use this script. Today, I stumbled upon a similar utility named **“Arch-wiki-man”**. As the name says, it is also used to read the Arch Wiki from command line, but it doesn’t require Internet connection. Arch-wiki-man program helps you to browse and read entire Arch Wiki as Linux man pages. It will display any article from Arch Wiki in man pages format. Also, you need not to be online to browse Arch Wiki. The entire Arch Wiki will be downloaded locally and the updates are pushed automatically every two days. So, you always have an up-to-date, local copy of the Arch Wiki on your system.
|
||||
|
||||
### Installing Arch-wiki-man
|
||||
|
||||
Arch-wiki-man is available in [**AUR**][2], so you can install it using any AUR helper programs, for example [**Yay**][3].
|
||||
|
||||
```
|
||||
$ yay -S arch-wiki-man
|
||||
```
|
||||
|
||||
Alternatively, it can be installed using NPM package manager like below. Make sure you have [**installed NodeJS**][4] and run the following command to install it:
|
||||
|
||||
```
|
||||
$ npm install -g arch-wiki-man
|
||||
```
|
||||
|
||||
### Browse And Read Entire Arch Wiki As Linux Man Pages
|
||||
|
||||
The typical syntax of Arch-wiki-man is:
|
||||
|
||||
```
|
||||
$ awman <search-query>
|
||||
```
|
||||
|
||||
Let me show you some examples.
|
||||
|
||||
**Search with one or more matches**
|
||||
|
||||
Let us search for a [**Arch Linux installation guide**][5]. To do so, simply run:
|
||||
|
||||
```
|
||||
$ awman Installation guide
|
||||
```
|
||||
|
||||
The above command will search for the matches that contains the search term “Installation guide” in the Arch Wiki. If there are multiple matches for the given search term, a selection menu will appear. Choose the guide you want to read using **UP/DOWN arrows** or Vim-style keybindings ( **j/k** ) and hit ENTER to open it. The resulting guide will open in man pages format like below.
|
||||
|
||||
![][6]
|
||||
|
||||
Here, awman refers **a** rch **w** iki **m** an.
|
||||
|
||||
All man command options are supported, so you can navigate through guide as the way you do when reading a man page. To view the help section, press **h**.
|
||||
|
||||
![][7]
|
||||
|
||||
To exit the selection menu without entering **man** , simply press **Ctrl+c**.
|
||||
|
||||
To go back and/or quit man, type **q**.
|
||||
|
||||
**Search matches in titles and descriptions**
|
||||
|
||||
By default, Awman will search for the matches in titles only. You can, however, direct it to search for the matches in both the titles and descriptions as well.
|
||||
|
||||
```
|
||||
$ awman -d vim
|
||||
```
|
||||
|
||||
Or,
|
||||
|
||||
```
|
||||
$ awman --desc-search vim
|
||||
```
|
||||
|
||||
**Search for matches in contents**
|
||||
|
||||
Apart from searching for matches in titles and descriptions, it is also possible to scan the contents for a match as well. Please note that this will significantly slower the search process.
|
||||
|
||||
```
|
||||
$ awman -k emacs
|
||||
```
|
||||
|
||||
Or,
|
||||
|
||||
```
|
||||
$ awman --apropos emacs
|
||||
```
|
||||
|
||||
**Open the search results in web browser**
|
||||
|
||||
If you don’t want to view the arch wiki guides in man page format, you can open it in a web browser. To do so, run:
|
||||
|
||||
```
|
||||
$ awman -w pacman
|
||||
```
|
||||
|
||||
Or,
|
||||
|
||||
```
|
||||
$ awman --web pacman
|
||||
```
|
||||
|
||||
This command will open the resulting match in the default web browser rather than with **man** command. Please note that you need Internet connection to use this option.
|
||||
|
||||
**Search in other languages**
|
||||
|
||||
By default, Awman will open the Arch wiki pages in English. If you want to view the results in other languages, for example **Spanish** , simply do:
|
||||
|
||||
```
|
||||
$ awman -l spanish codecs
|
||||
```
|
||||
|
||||
![][8]
|
||||
|
||||
To view the list of available language options, run:
|
||||
|
||||
```
|
||||
|
||||
$ awman --list-languages
|
||||
|
||||
```
|
||||
|
||||
**Update the local copy of Arch Wiki**
|
||||
|
||||
Like I already said, the updates are pushed automatically every two days. If you want to update it manually, simply run:
|
||||
|
||||
```
|
||||
$ awman-update
|
||||
arch-wiki-man@1.3.0 /usr/lib/node_modules/arch-wiki-man
|
||||
└── arch-wiki-md-repo@0.10.84
|
||||
|
||||
arch-wiki-md-repo has been successfully updated or reinstalled.
|
||||
```
|
||||
|
||||
Cheers!
|
||||
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.ostechnix.com/how-to-browse-and-read-entire-arch-wiki-as-linux-man-pages/
|
||||
|
||||
作者：[SK][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://www.ostechnix.com/author/sk/
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://www.ostechnix.com/search-arch-wiki-website-commandline/
|
||||
[2]: https://aur.archlinux.org/packages/arch-wiki-man/
|
||||
[3]: https://www.ostechnix.com/yay-found-yet-another-reliable-aur-helper/
|
||||
[4]: https://www.ostechnix.com/install-node-js-linux/
|
||||
[5]: https://www.ostechnix.com/install-arch-linux-latest-version/
|
||||
[6]: http://www.ostechnix.com/wp-content/uploads/2018/10/awman-1.gif
|
||||
[7]: http://www.ostechnix.com/wp-content/uploads/2018/10/awman-2.png
|
||||
[8]: https://www.ostechnix.com/wp-content/uploads/2018/10/awman-3-1.png
|
||||
@ -1,3 +1,4 @@
|
||||
Translating by qhwdw
|
||||
Final JOS project
|
||||
======
|
||||
Piazza Discussion Due, November 2, 2018 Proposals Due, November 8, 2018 Code repository Due, December 6, 2018 Check-off and in-class demos, Week of December 10, 2018
|
||||
|
||||
@ -1,3 +1,4 @@
|
||||
Translating by qhwdw
|
||||
Lab 4: Preemptive Multitasking
|
||||
======
|
||||
### Lab 4: Preemptive Multitasking
|
||||
|
||||
@ -1,3 +1,4 @@
|
||||
Translating by qhwdw
|
||||
Lab 5: File system, Spawn and Shell
|
||||
======
|
||||
|
||||
|
||||
@ -1,3 +1,4 @@
|
||||
Translating by qhwdw
|
||||
Lab 6: Network Driver
|
||||
======
|
||||
### Lab 6: Network Driver (default final project)
|
||||
|
||||
@ -1,3 +1,5 @@
|
||||
translating---geekpi
|
||||
|
||||
Turn Your Old PC into a Retrogaming Console with Lakka Linux
|
||||
======
|
||||
**If you have an old computer gathering dust, you can turn it into a PlayStation like retrogaming console with Lakka Linux distribution. **
|
||||
|
||||
@ -0,0 +1,94 @@
|
||||
4 open source alternatives to Microsoft Access
|
||||
======
|
||||
Build simple business applications and keep track of your data with these worthy open source alternatives.
|
||||
|
||||
|
||||
When small businesses, community organizations, and similar-sized groups realize they need software to manage their data, they think first of Microsoft Access. That may be the right choice if you're already paying for a Microsoft Office subscription or don't care that it's proprietary. But it's far from your only option—whether you prefer to use open source alternatives from a philosophical standpoint or you don't have the big budget for a Microsoft Office subscription—there are several open source database applications that are worthy alternatives to proprietary software like Microsoft Access or Apple FileMaker.
|
||||
|
||||
If that sounds like you, here are four open source database tools for your consideration.
|
||||
|
||||
### LibreOffice Base
|
||||
|
||||
|
||||
In case it's not obvious from its name, [Base][1] is part of the [LibreOffice][2] productivity suite, which includes Writer (word processing), Calc (spreadsheet), Impress (presentations), Draw (graphics), Charts (chart creation), and Math (formulas). As such, Base integrates with the other LibreOffice applications, much like Access does with the Microsoft Office suite. This means you can import and export data from Base into the suite's other applications to create financial reports, mail merges, charts, and more.
|
||||
|
||||
Base includes drivers that natively support multi-user database engines, including the open source MySQL, MariaDB, and PostgreSQL; Access; and other JDBC and ODBC-compliant databases. Built-in wizards and table definitions make it easy for new users to quickly get started building tables, writing queries, and creating forms and reports (such as invoices, sales reports, and customer lists). To learn more, consult the comprehensive [user manual][3] and dive into the [user forums][4]. If you're still stuck, you can find a [certified][5] support professional to help you out.
|
||||
|
||||
Installers are available for Linux, MacOS, Windows, and Android. LibreOffice is available under the [Mozilla Public License v2][6]; if you'd like to join the large contributor community and help improve the software, visit the [Get Involved][7] section of LibreOffice's website.
|
||||
|
||||
### DB Browser for SQLite
|
||||
|
||||
|
||||
|
||||
[DB Browser for SQLite][8] enables users to create and use SQLite database files without having to know complex SQL commands. This, plus its spreadsheet-like interface and pre-built wizards, make it a great option for new database users to get going without much background knowledge.
|
||||
|
||||
Although the application has gone through several name changes—from the original Arca Database Browser to the SQLite Database Browser and finally to the current name (in 2014, to avoid confusion with SQLite), it's stayed true to its goal of being easy for users to operate.
|
||||
|
||||
Its wizards enable users to easily create and modify database files, tables, indexes, records, etc.; import and export data to common file formats; create and issue queries and searches; and more. Installers are available for Windows, MacOS, and a variety of Linux versions, and its [wiki on GitHub][9] offers a wealth of information for users and developers.
|
||||
|
||||
DB Browser for SQLite is [bi-licensed][10] under the Mozilla Public License Version 2 and the GNU General Public License Version 3 or later, and you can download the source code from the project's website.
|
||||
|
||||
### Kexi
|
||||
|
||||
|
||||
As the database application in the [Calligra Suite][11] productivity software for the KDE desktop, [Kexi][12] integrates with the other applications in the suite, including Words (word processing), Sheets (spreadsheet), Stage (presentations), and Plan (project management).
|
||||
|
||||
As a full member of the [KDE][13] project, Kexi is purpose-built for KDE Plasma, but it's not limited to KDE users: Linux, BSD, and Unix users running GNOME can run the database, as can MacOS and Windows users.
|
||||
|
||||
Kexi's website says its development was "motivated by the lack of rapid application development ([RAD][14]) tools for database systems that are sufficiently powerful, inexpensive, open standards driven, and portable across many operating systems and hardware platforms." It has all the standard features you'd expect: designing databases, storing data, doing queries, processing data, and so forth.
|
||||
|
||||
Kexi is available under the [LGPL][15] open source license and you can download its [source code][16] from its development wiki. If you'd like to learn more, take a look at its [user handbook][17], [forums][18], and [userbase wiki][17].
|
||||
|
||||
### nuBuilder Forte
|
||||
|
||||
|
||||
[NuBuilder Forte][19] is designed to be as easy as possible for people to use. It's a browser-based tool for developing web-based database applications.
|
||||
|
||||
Its clean interface and low-code tools (including support for drag-and-drop) allow users to create and use a database quickly. As a fully web-based application, data is accessible anywhere from a browser. Everything is stored in MySQL and can be backed up in one database file.
|
||||
|
||||
It uses industry-standard coding languages—HTML, PHP, JavaScript, and SQL—making it easy for developers to get started also.
|
||||
|
||||
Help is available in [videos][20] and other [documentation][21] for topics including creating forms, doing searches, building reports, and more.
|
||||
|
||||
nuBuilder Forte is licensed under [GPLv3.0][22] and you can download it on [GitHub][23]. You can learn more by consulting the [nuBuilder Forum][24] or watching its [demo][25] video.
|
||||
|
||||
Do you have a favorite open source database tool for building simple projects with little or no coding skill required? If so, please share in the comments.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/alternatives/access
|
||||
|
||||
作者：[Opensource.com][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
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://www.libreoffice.org/discover/base/
|
||||
[2]: https://www.libreoffice.org/
|
||||
[3]: https://documentation.libreoffice.org/en/english-documentation/base/
|
||||
[4]: http://document-foundation-mail-archive.969070.n3.nabble.com/Users-f1639498.html
|
||||
[5]: https://www.libreoffice.org/get-help/professional-support/
|
||||
[6]: https://www.libreoffice.org/download/license/
|
||||
[7]: https://www.libreoffice.org/community/get-involved/
|
||||
[8]: http://sqlitebrowser.org/
|
||||
[9]: https://github.com/sqlitebrowser/sqlitebrowser/wiki
|
||||
[10]: https://github.com/sqlitebrowser/sqlitebrowser/blob/master/LICENSE
|
||||
[11]: https://www.calligra.org/
|
||||
[12]: https://www.calligra.org/kexi/
|
||||
[13]: https://www.kde.org/
|
||||
[14]: http://en.wikipedia.org/wiki/Rapid_application_development
|
||||
[15]: http://kexi-project.org/wiki/wikiview/index.php@KexiLicense.html
|
||||
[16]: http://kexi-project.org/wiki/wikiview/index.php@Download.html
|
||||
[17]: https://userbase.kde.org/Kexi/Handbook
|
||||
[18]: http://forum.kde.org/kexi
|
||||
[19]: https://www.nubuilder.com/
|
||||
[20]: https://www.nubuilder.com/videos
|
||||
[21]: https://www.nubuilder.com/wiki
|
||||
[22]: https://github.com/nuSoftware/nuBuilder4/blob/master/LICENSE.txt
|
||||
[23]: https://github.com/nuSoftware/nuBuilder4
|
||||
[24]: https://forums.nubuilder.com/viewforum.php?f=18&sid=7036bccdc08ba0da73181bc72cd63c62
|
||||
[25]: https://www.youtube.com/watch?v=tdh9ILCUAco&feature=youtu.be
|
||||
@ -0,0 +1,74 @@
|
||||
MidnightBSD Hits 1.0! Checkout What’s New
|
||||
======
|
||||
A couple days ago, Lucas Holt announced the release of MidnightBSD 1.0. Let’s take a quick look at what is included in this new release.
|
||||
|
||||
### What is MidnightBSD?
|
||||
|
||||
![MidnightBSD][1]
|
||||
|
||||
[MidnightBSD][2] is a fork of FreeBSD. Lucas created MightnightBSD to be an option for desktop users and for BSD newbies. He wanted to create something that would allow people to quickly get a desktop experience on BSD. He believed that other options had too much of a focus on the server market.
|
||||
|
||||
### What is in MidnightBSD 1.0?
|
||||
|
||||
According to the [release notes][3], most of the work in 1.0 went towards updating the base system, improving the package manager and updating tools. The new release is compatible with FreeBSD 10-Stable.
|
||||
|
||||
Mports (MidnightBSD’s package management system) has been upgraded to support installing multiple packages with one command. The `mport upgrade` command has been fixed. Mports now tracks deprecated and expired packages. A new package format was also introduced.
|
||||
|
||||
<https://www.youtube.com/embed/-rlk2wFsjJ4>
|
||||
|
||||
Other changes include:
|
||||
|
||||
* [ZFS][4] is now supported as a boot file system. Previously, ZFS could only be used for additional storage.
|
||||
* Support for NVME SSDs
|
||||
* AMD Ryzen and Radeon support have been improved.
|
||||
* Intel, Broadcom, and other drivers updated.
|
||||
* bhyve support has been ported from FreeBSD
|
||||
* The sensors framework was removed because it was causing locking issues.
|
||||
* Sudo was removed and replaced with [doas][5] from OpenBSD.
|
||||
* Added support for Microsoft hyper-v
|
||||
|
||||
|
||||
|
||||
### Before you upgrade…
|
||||
|
||||
If you are a current MidnightBSD user or are thinking of trying out the new release, it would be a good idea to wait. Lucas is currently rebuilding packages to support the new package format and tooling. He also plans to upgrade packages and ports for the desktop environment over the next couple of months. He is currently working on porting Firefox 52 ESR because it is the last release that does not require Rust. He also hopes to get a newer version of Chromium ported to MidnightBSD. I would recommend keeping an eye on the MidnightBSD [Twi][6][t][6][ter][6] feed.
|
||||
|
||||
### What happened to 0.9?
|
||||
|
||||
You might notice that the previous release of MidnightBSD was 0.8.6. Now, you might be wondering “Why the jump to 1.0”? According to Lucas, he ran into several issues while developing 0.9. In fact, he restarted it several times. He ending up taking CURRENT in a different direction than the 0.9 branch and it became 1.0. Some packages also had an issue with the 0.* numbering system.
|
||||
|
||||
### Help Needed
|
||||
|
||||
Currently, the MidnightBSD project is the work of pretty much one guy, Lucas Holt. This is the main reason why development has been slow. If you are interested in helping out, you can contact him on [Twitter][6].
|
||||
|
||||
In the [release announcement video][7]. Lucas said that he had encountered problems with upstream projects accepting patches. They seem to think that MidnightBSD is too small. This often means that he has to port an application from scratch.
|
||||
|
||||
### Thoughts
|
||||
|
||||
I have a thing for the underdog. Of all the BSDs that I have interacted with, that monicker fits MidnightBSD the most. One guy trying to create an easy desktop experience. Currently, there is only one other BSD trying to do something similar: Project Trident. I think that this is a real barrier to BSDs success. Linux succeeds because people can quickly and easily install it. Hopefully, MidnightBSD does that for BSD, but right now it has a long way to go.
|
||||
|
||||
Have you ever used MidnightBSD? If not, what is your favorite BSD? What other BSD topics should we cover? Let us know in the comments below.
|
||||
|
||||
If you found this article interesting, please take a minute to share it on social media, Hacker News or [Reddit][8].
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://itsfoss.com/midnightbsd-1-0-release/
|
||||
|
||||
作者：[John Paul][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://itsfoss.com/author/john/
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://4bds6hergc-flywheel.netdna-ssl.com/wp-content/uploads/2018/10/midnightbsd-wallpaper.jpeg
|
||||
[2]: https://www.midnightbsd.org/
|
||||
[3]: https://www.midnightbsd.org/notes/
|
||||
[4]: https://itsfoss.com/what-is-zfs/
|
||||
[5]: https://man.openbsd.org/doas
|
||||
[6]: https://twitter.com/midnightbsd
|
||||
[7]: https://www.youtube.com/watch?v=-rlk2wFsjJ4
|
||||
[8]: http://reddit.com/r/linuxusersgroup
|
||||
@ -0,0 +1,82 @@
|
||||
TimelineJS: An interactive, JavaScript timeline building tool
|
||||
======
|
||||
Learn how to tell a story with TimelineJS.
|
||||
|
||||
|
||||
[TimelineJS 3][1] is an open source storytelling tool that anyone can use to create visually rich, interactive timelines to post on their websites. To get started, simply click “Make a Timeline” on the homepage and follow the easy [step-by-step instructions][1].
|
||||
|
||||
TimelineJS was developed at Northwestern University’s KnightLab in Evanston, Illinois. KnightLab is a community of designers, developers, students, and educators who work on experiments designed to push journalism into new spaces. TimelineJS has been used by more than 250,000 people, according to its website, to tell stories viewed millions of times. And TimelineJS3 is available in more than 60 languages.
|
||||
|
||||
Joe Germuska, the “chief nerd” who runs KnightLab’s technology, professional staff, and student fellows, explains, "TimelineJS was originally developed by Northwestern professor Zach Wise. He assigned his students a task to tell stories in a timeline format, only to find that none of the free available tools were as good as he thought they could be. KnightLab funded some of his time to develop the tool in 2012. Near the end of that year, I joined the lab, and among my early tasks was to bring TimelineJS in as a fully supported project of the lab. The next year, I helped Zach with a rewrite to address some issues. Along the way, many students have contributed. Interestingly, a group of students from Victoria University in Wellington, New Zealand, worked on TimelineJS (and some of our other tools) as part of a class project in 2016."
|
||||
|
||||
"In general, we designed TimelineJS to make it easy for non-technical people to tell rich, dynamic stories on the web in the context of events in time.”
|
||||
|
||||
Users create timelines by adding content into a Google spreadsheet. KnightLab provides a downloadable template that can be edited to create custom timelines. Experts can use their JSON skills to [create custom installations][2] while keeping TimelineJS’s core functionality.
|
||||
|
||||
This easy-to-follow [Vimeo video][3] shows how to get started with TimelineJS, and I used it myself to create my first timeline.
|
||||
|
||||
### Open sourcing the Adirondacks
|
||||
|
||||
Reid Larson, research and scholarly communication librarian at Hamilton College in Clinton, New York, began searching for ways to combine open data and visualization to chronicle the history of Essex County (a county in northern New York that makes up part of the Adirondacks), in the 1990s, when he was the director of the Essex County Historical Society/Adirondack History Center Museum.
|
||||
|
||||
"I wanted to take all the open data available on the history of Essex County and be able to present it to people visually. Most importantly, I wanted to make sure that the data would be available for use even if the applications used to present it are no longer available or supported," Larson explains.
|
||||
|
||||
Now at Hamilton College, Larson has found TimelineJS to be the ideal open source program to do just what he wanted: Chronicle and present a visually appealing timeline of selected places.
|
||||
|
||||
"It was a professor who was working on a project that required a solution such as Timeline, and after researching the possibilities, I started using Timeline for that project and subsequent projects," Larson adds.
|
||||
|
||||
TimelineJS can be used via a web browser, or the source code can be downloaded from [GitHub][4] for local use.
|
||||
|
||||
"I’ve been using the browser version, but I push it to the limits to see how far I can go with it, such as adding my own HTML tags. I want to fully understand it so that I can educate the students and faculty at Hamilton College on its uses," Larson says.
|
||||
|
||||
### An open source Eagle Scout project
|
||||
|
||||
Not only has Larson used TimelineJS for collegiate purposes, but his son, Erik, created an [interactive historical website][5] for his Eagle Scout project in 2017 using WordPress. The project is a chronicle of places in Waterville, New York, just south of Clinton, in Oneida County. Erik explains that he wants what he started to expand beyond the 36 places in Waterville. "The site is an experiment in online community building," Erik’s website reads.
|
||||
|
||||
Larson says he did a lot of the “tech work” on the project so that Erik could concentrate on content. The site was created with [Omeka][6], an open source web publishing platform for sharing digital collections and creating media-rich online exhibits, and [Curatescape][7], a framework for the open source Omeka CMS.
|
||||
|
||||
Larson explains that a key feature of TimelineJS is that it uses Google Sheets to store and organize the data used in the timeline. "Google Sheets is a good structure for organizing data simply, and that data will be available even if TimelineJS becomes unavailable in the future."
|
||||
|
||||
Larson says that he prefers using [ArcGIS][8] over KnightLab’s StoryMap because it uses spreadsheets to store content, whereas [StoryMap][9] does not. Larson is looking forward to integrating augmented reality into his projects in the future.
|
||||
|
||||
### Create your own open source timeline
|
||||
|
||||
I plan on using TimelineJS to create interactive content for the Development and Alumni Relations department at Clarkson University, where I am the development communications specialist. To practice with working with it, I created [a simple timeline][10] of the articles I’ve written for [Opensource.com][11]:
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
As Reid Larson stated, it is very easy to use and the results are quite satisfactory. I was able to get a working timeline created and posted to my WordPress site in a matter of minutes. I used media that I had already uploaded to my Media Library in WordPress and simply copied the image address. I typed in the dates, locations, and information in the other cells and used “publish to web” under “file” in the Google spreadsheet. That produced a link and embed code. I created a new post in my WordPress site and pasted in the embed code, and the timeline was live and working.
|
||||
|
||||
Of course, there is more customization I need to do, but I was able to get it working quickly and easily, much as Reid said it would.
|
||||
|
||||
I will continue experimenting with TimelineJS on my own site, and when I get more comfortable with it, I’ll use it for my professional projects and try out the other apps that KnightLab has created for interactive, visually appealing storytelling.
|
||||
|
||||
What might you use TimelineJS for?
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/18/10/create-interactive-timelines-open-source-tool
|
||||
|
||||
作者：[Jeff Macharyas][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/rikki-endsley
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://timeline.knightlab.com/
|
||||
[2]: https://timeline.knightlab.com/docs/json-format.html
|
||||
[3]: https://vimeo.com/knightlab/timelinejs
|
||||
[4]: https://github.com/NUKnightLab/TimelineJS3
|
||||
[5]: http://nysplaces.com/
|
||||
[6]: https://github.com/omeka
|
||||
[7]: https://github.com/CPHDH/Curatescape
|
||||
[8]: https://www.arcgis.com/index.html
|
||||
[9]: https://storymap.knightlab.com/
|
||||
[10]: https://macharyas.com/index.php/2018/10/06/timeline/
|
||||
[11]: http://opensource.com/
|
||||
File diff suppressed because it is too large
Load Diff
390
translated/tech/20180912 How to build rpm packages.md
Normal file
390
translated/tech/20180912 How to build rpm packages.md
Normal file
@ -0,0 +1,390 @@
|
||||
如何构建rpm包
|
||||
======
|
||||
|
||||
节省跨多个主机安装文件和脚本的时间和精力。
|
||||
|
||||
|
||||
|
||||
自20多年前我开始使用 Linux 以来，我已经使用过基于 rpm 的软件包管理器在 Red Hat 和 Fedora Linux系统上安装软件。我使用过 **rpm** 程序本身，还有 **yum** 和 **DNF** ，用于在我的 Linux 主机上安装和更新软件包，DNF 是 yum 的一个紧密后代。 yum 和 DNF 工具是 rpm 实用程序的包装器，它提供了其他功能，例如查找和安装包依赖项的功能。
|
||||
|
||||
多年来，我创建了许多 Bash 脚本，其中一些脚本具有单独的配置文件，我希望在大多数新计算机和虚拟机上安装这些脚本。这也能解决安装所有这些软件包需要花费大量时间的难题，因此我决定通过创建一个 rpm 软件包来自动执行该过程，我可以将其复制到目标主机并将所有这些文件安装在适当的位置。虽然 **rpm** 工具以前用于构建 rpm 包，但该功能已被删除，并且创建了一个新工具来构建新的 rpm。
|
||||
|
||||
当我开始这个项目时，我发现很少有关于创建 rpm 包的信息，但我找到了一本书，名为《Maximum RPM》，这本书才帮我弄明白了。这本书现在已经过时了，我发现的绝大多数信息都是如此。它也已经绝版，使用复印件需要花费数百美元。[Maximum RPM][1] 的在线版本是免费提供的，并保持最新。 [RPM 网站][2]还有其他网站的链接，这些网站上有很多关于 rpm 的文档。其他的信息往往是简短的，显然都是假设你已经对该过程有了很多了解。
|
||||
|
||||
此外，我发现的每个文档都假定代码需要在开发环境中从源代码编译。我不是开发人员。我是一个系统管理员，我们系统管理员有不同的需求，因为我们不需要或者我们不应该为了管理任务而去编译代码;我们应该使用 shell 脚本。所以我们没有源代码，因为它需要被编译成二进制可执行文件。我们拥有的是一个也是可执行的源代码。
|
||||
|
||||
在大多数情况下，此项目应作为非 root 用户执行。 Rpm 包永远不应该由 root 用户构建，而只能由非特权普通用户构建。我将指出哪些部分应该以 root 身份执行，哪些部分应由非 root，非特权用户执行。
|
||||
|
||||
### 准备
|
||||
|
||||
首先，打开一个终端会话，然后 `su` 到 root 用户。 请务必使用 `-` 选项以确保启用完整的 root 环境。 我不认为系统管理员应该使用 `sudo` 来执行任何管理任务。 在我的个人博客文章中可以找出为什么：[真正的系统管理员不要使用 sudo][3]。
|
||||
|
||||
```
|
||||
[student@testvm1 ~]$ su -
|
||||
Password:
|
||||
[root@testvm1 ~]#
|
||||
```
|
||||
|
||||
创建可用于此项目的普通用户 student，并为该用户设置密码。
|
||||
|
||||
```
|
||||
[root@testvm1 ~]# useradd -c "Student User" student
|
||||
[root@testvm1 ~]# passwd student
|
||||
Changing password for user student.
|
||||
New password: <Enter the password>
|
||||
Retype new password: <Enter the password>
|
||||
passwd: all authentication tokens updated successfully.
|
||||
[root@testvm1 ~]#
|
||||
```
|
||||
|
||||
构建 rpm 包需要 `rpm-build` 包，该包可能尚未安装。 现在以 root 身份安装它。 请注意，此命令还将安装多个依赖项。 数量可能会有所不同，具体取决于主机上已安装的软件包； 它在我的测试虚拟机上总共安装了17个软件包，这是非常小的。
|
||||
|
||||
```
|
||||
dnf install -y rpm-build
|
||||
```
|
||||
|
||||
除非另有明确指示，否则本项目的剩余部分应以普通用户用户 student 来执行。 打开另一个终端会话并使用 `su` 切换到该用户以执行其余步骤。 使用以下命令从 GitHub 下载我准备好的开发目录结构 utils.tar 这个<ruby>tar 包<rt>tarball</rt></ruby>（LCTT 译注：tarball 是以 tar 命令来打包和压缩的文件的统称）：
|
||||
|
||||
```
|
||||
wget https://github.com/opensourceway/how-to-rpm/raw/master/utils.tar
|
||||
```
|
||||
|
||||
此 tar 包包含将由最终 rpm 程序安装的所有文件和 Bash 脚本。 还有一个完整的 spec 文件，你可以使用它来构建 rpm。 我们将详细介绍 spec 文件的每个部分。
|
||||
|
||||
作为普通学生 student，使用你的家目录作为当前工作目录（pwd），解压缩 tar 包。
|
||||
|
||||
```
|
||||
[student@testvm1 ~]$ cd ; tar -xvf utils.tar
|
||||
```
|
||||
|
||||
使用 `tree` 命令验证~/development 的目录结构和包含的文件，如下所示：
|
||||
|
||||
```
|
||||
[student@testvm1 ~]$ tree development/
|
||||
development/
|
||||
├── license
|
||||
│ ├── Copyright.and.GPL.Notice.txt
|
||||
│ └── GPL_LICENSE.txt
|
||||
├── scripts
|
||||
│ ├── create_motd
|
||||
│ ├── die
|
||||
│ ├── mymotd
|
||||
│ └── sysdata
|
||||
└── spec
|
||||
└── utils.spec
|
||||
|
||||
3 directories, 7 files
|
||||
[student@testvm1 ~]$
|
||||
```
|
||||
|
||||
`mymotd` 脚本创建一个发送到标准输出的“当日消息”数据流。 `create_motd` 脚本运行 `mymotd` 脚本并将输出重定向到 /etc/motd 文件。 此文件用于向使用SSH远程登录的用户显示每日消息。
|
||||
|
||||
`die` 脚本是我自己的脚本，它将 `kill` 命令包装在一些代码中，这些代码可以找到与指定字符串匹配的运行程序并将其终止。 它使用 `kill -9` 来确保kill命令一定会执行。
|
||||
|
||||
`sysdata` 脚本可以显示有关计算机硬件，还有已安装的 Linux 版本，所有已安装的软件包以及硬盘驱动器元数据的数万行数据。 我用它来记录某个时间点的主机状态。 我以后可以用它作为参考。 我曾经这样做是为了维护我为客户安装的主机记录。
|
||||
|
||||
你可能需要将这些文件和目录的所有权更改为 student:student 。 如有必要，使用以下命令执行此操作：
|
||||
|
||||
```
|
||||
chown -R student:student development
|
||||
```
|
||||
|
||||
此文件树中的大多数文件和目录将通过你在此项目期间创建的 rpm 包安装在 Fedora 系统上。
|
||||
|
||||
### 创建构建目录结构
|
||||
|
||||
`rpmbuild` 命令需要非常特定的目录结构。 你必须自己创建此目录结构，因为没有提供自动方式。 在家目录中创建以下目录结构：
|
||||
|
||||
```
|
||||
~ ─ rpmbuild
|
||||
├── RPMS
|
||||
│ └── noarch
|
||||
├── SOURCES
|
||||
├── SPECS
|
||||
└── SRPMS
|
||||
```
|
||||
|
||||
我们不会创建 rpmbuild/RPMS/X86_64 目录，因为对于64位编译的二进制文件这是特定于体系结构的。 我们有 shell 脚本，不是特定于体系结构的。 实际上，我们也不会使用 SRPMS 目录，它将包含编译器的源文件。
|
||||
|
||||
### 检查 spec 文件
|
||||
|
||||
每个 spec 文件都有许多部分，其中一些部分可能会被忽视或省略，取决于 rpm 构建的具体情况。 这个特定的 spec 文件不是工作所需的最小文件的示例，但它是一个很好的包含不需要编译的文件的中等复杂 spec 文件的例子。 如果需要编译，它将在`构建`部分中执行，该部分在此 spec 文件中省略掉了，因为它不是必需的。
|
||||
|
||||
#### 前言
|
||||
|
||||
这是 spec 文件中唯一没有标签的部分。 它包含运行命令 `rpm -qi [Package Name]` 时看到的大部分信息。 每个数据都是一行，由标签和标签值的文本数据组成。
|
||||
|
||||
```
|
||||
###############################################################################
|
||||
# Spec file for utils
|
||||
################################################################################
|
||||
# Configured to be built by user student or other non-root user
|
||||
################################################################################
|
||||
#
|
||||
Summary: Utility scripts for testing RPM creation
|
||||
Name: utils
|
||||
Version: 1.0.0
|
||||
Release: 1
|
||||
License: GPL
|
||||
URL: http://www.both.org
|
||||
Group: System
|
||||
Packager: David Both
|
||||
Requires: bash
|
||||
Requires: screen
|
||||
Requires: mc
|
||||
Requires: dmidecode
|
||||
BuildRoot: ~/rpmbuild/
|
||||
|
||||
# Build with the following syntax:
|
||||
# rpmbuild --target noarch -bb utils.spec
|
||||
```
|
||||
|
||||
`rpmbuild` 程序会忽略注释行。我总是喜欢在本节中添加注释，其中包含创建包所需的 `rpmbuild` 命令的确切语法。摘要标签是包的简短描述。 Name，Version 和 Release 标签用于创建 rpm 文件的名称，如utils-1.00-1.rpm 中所示。通过增加发行版号码和版本号，你可以创建 rpm 包去更新旧版本的。
|
||||
|
||||
许可证标签定义了发布包的许可证。我总是使用 GPL 的一个变体。指定许可证对于澄清包中包含的软件是开源的这一事实非常重要。这也是我将许可证和 GPL 语句包含在将要安装的文件中的原因。
|
||||
|
||||
URL 通常是项目或项目所有者的网页。在这种情况下，它是我的个人网页。
|
||||
|
||||
Group 标签很有趣，通常用于 GUI 应用程序。 Group 标签的值决定了应用程序菜单中的哪一组图标将包含此包中可执行文件的图标。与 Icon 标签（我们此处未使用）一起使用时，Group 标签允许添加图标和所需信息用于将程序启动到应用程序菜单结构中。
|
||||
|
||||
Packager 标签用于指定负责维护和创建包的人员或组织。
|
||||
|
||||
Requires 语句定义此 rpm 包的依赖项。每个都是包名。如果其中一个指定的软件包不存在，DNF 安装实用程序将尝试在 /etc/yum.repos.d 中定义的某个已定义的存储库中找到它，如果存在则安装它。如果 DNF 找不到一个或多个所需的包，它将抛出一个错误，指出哪些包丢失并终止。
|
||||
|
||||
BuildRoot 行指定顶级目录，`rpmbuild` 工具将在其中找到 spec 文件，并在构建包时在其中创建临时目录。完成的包将存储在我们之前指定的noarch子目录中。注释显示了构建此程序包的命令语法，包括定义了目标体系结构的 `–target noarch` 选项。因为这些是Bash脚本，所以它们与特定的CPU架构无关。如果省略此选项，则构建将选用正在执行构建的CPU的体系结构。
|
||||
|
||||
`rpmbuild` 程序可以针对许多不同的体系结构，并且使用 `--target` 选项允许我们在不同的体系结构主机上构建特定体系结构的包，其具有与执行构建的体系结构不同的体系结构。所以我可以在 x86_64 主机上构建一个用于 i686 架构的软件包，反之亦然。
|
||||
|
||||
如果你有自己的网站，请将打包者的名称更改为你自己的网站。
|
||||
|
||||
#### 描述
|
||||
|
||||
spec 文件的 `描述` 部分包含 rpm 包的描述。 它可以很短，也可以包含许多信息。 我们的 `描述` 部分相当简洁。
|
||||
|
||||
```
|
||||
%description
|
||||
A collection of utility scripts for testing RPM creation.
|
||||
```
|
||||
|
||||
#### 准备
|
||||
|
||||
`准备` 部分是在构建过程中执行的第一个脚本。 在安装程序包期间不会执行此脚本。
|
||||
|
||||
这个脚本只是一个 Bash shell 脚本。 它准备构建目录，根据需要创建用于构建的目录，并将相应的文件复制到各自的目录中。 这将包括完整编译作为构建的一部分所需的源。
|
||||
|
||||
$RPM_BUILD_ROOT 目录表示已安装系统的根目录。 在 $RPM_BUILD_ROOT 目录中创建的目录是实时文件系统中的绝对路径，例如 /user/local/share/utils，/usr/local/bin 等。
|
||||
|
||||
对于我们的包，我们没有预编译源，因为我们的所有程序都是 Bash 脚本。 因此，我们只需将这些脚本和其他文件复制到已安装系统的目录中。
|
||||
|
||||
```
|
||||
%prep
|
||||
################################################################################
|
||||
# Create the build tree and copy the files from the development directories #
|
||||
# into the build tree. #
|
||||
################################################################################
|
||||
echo "BUILDROOT = $RPM_BUILD_ROOT"
|
||||
mkdir -p $RPM_BUILD_ROOT/usr/local/bin/
|
||||
mkdir -p $RPM_BUILD_ROOT/usr/local/share/utils
|
||||
|
||||
cp /home/student/development/utils/scripts/* $RPM_BUILD_ROOT/usr/local/bin
|
||||
cp /home/student/development/utils/license/* $RPM_BUILD_ROOT/usr/local/share/utils
|
||||
cp /home/student/development/utils/spec/* $RPM_BUILD_ROOT/usr/local/share/utils
|
||||
|
||||
exit
|
||||
```
|
||||
|
||||
请注意，本节末尾的 exit 语句是必需的。
|
||||
|
||||
#### 文件
|
||||
|
||||
spec 文件的这一部分定义了要安装的文件及其在目录树中的位置。 它还指定了要安装的每个文件的文件属性以及所有者和组所有者。 文件权限和所有权是可选的，但我建议明确设置它们以消除这些属性在安装时不正确或不明确的任何可能性。 如果目录尚不存在，则会在安装期间根据需要创建目录。
|
||||
|
||||
```
|
||||
%files
|
||||
%attr(0744, root, root) /usr/local/bin/*
|
||||
%attr(0644, root, root) /usr/local/share/utils/*
|
||||
```
|
||||
|
||||
#### 安装前
|
||||
|
||||
在我们的实验室项目的 spec 文件中，此部分为空。 这将放置那些需要 rpm 安装前执行的脚本。
|
||||
|
||||
#### 安装后
|
||||
|
||||
spec 文件的这一部分是另一个 Bash 脚本。 这个在安装文件后运行。 此部分几乎可以是你需要或想要的任何内容，包括创建文件，运行系统命令以及重新启动服务以在进行配置更改后重新初始化它们。 我们的 rpm 包的 `安装后` 脚本执行其中一些任务。
|
||||
|
||||
```
|
||||
%post
|
||||
################################################################################
|
||||
# Set up MOTD scripts #
|
||||
################################################################################
|
||||
cd /etc
|
||||
# Save the old MOTD if it exists
|
||||
if [ -e motd ]
|
||||
then
|
||||
cp motd motd.orig
|
||||
fi
|
||||
# If not there already, Add link to create_motd to cron.daily
|
||||
cd /etc/cron.daily
|
||||
if [ ! -e create_motd ]
|
||||
then
|
||||
ln -s /usr/local/bin/create_motd
|
||||
fi
|
||||
# create the MOTD for the first time
|
||||
/usr/local/bin/mymotd > /etc/motd
|
||||
```
|
||||
|
||||
此脚本中包含的注释应明确其用途。
|
||||
|
||||
#### 卸载后
|
||||
|
||||
此部分包含将在卸载 rpm 软件包后运行的脚本。 使用 rpm 或 DNF 删除包会删除文件部分中列出的所有文件，但它不会删除安装后部分创建的文件或链接，因此我们需要在本节中处理。
|
||||
|
||||
此脚本通常由清理任务组成，只是清除以前由rpm安装的文件，但rpm本身无法完成清除。 对于我们的包，它包括删除 `安装后` 脚本创建的链接并恢复 motd 文件的已保存原件。
|
||||
|
||||
```
|
||||
%postun
|
||||
# remove installed files and links
|
||||
rm /etc/cron.daily/create_motd
|
||||
|
||||
# Restore the original MOTD if it was backed up
|
||||
if [ -e /etc/motd.orig ]
|
||||
then
|
||||
mv -f /etc/motd.orig /etc/motd
|
||||
fi
|
||||
```
|
||||
|
||||
#### 清理
|
||||
|
||||
这个 Bash 脚本在 rpm 构建过程之后开始清理。 下面 `清理` 部分中的两行删除了 `rpm-build` 命令创建的构建目录。 在许多情况下，可能还需要额外的清理。
|
||||
|
||||
```
|
||||
%clean
|
||||
rm -rf $RPM_BUILD_ROOT/usr/local/bin
|
||||
rm -rf $RPM_BUILD_ROOT/usr/local/share/utils
|
||||
```
|
||||
|
||||
#### 更新日志
|
||||
|
||||
此可选的文本部分包含 rpm 及其包含的文件的更改列表。 最新的更改记录在本部分顶部。
|
||||
|
||||
```
|
||||
%changelog
|
||||
* Wed Aug 29 2018 Your Name <Youremail@yourdomain.com>
|
||||
- The original package includes several useful scripts. it is
|
||||
primarily intended to be used to illustrate the process of
|
||||
building an RPM.
|
||||
```
|
||||
|
||||
使用你自己的姓名和电子邮件地址替换标题行中的数据。
|
||||
|
||||
### 构建 rpm
|
||||
|
||||
spec 文件必须位于 rpmbuild 目录树的 SPECS 目录中。 我发现最简单的方法是创建一个指向该目录中实际 spec 文件的链接，以便可以在开发目录中对其进行编辑，而无需将其复制到 SPECS 目录。 将 SPECS 目录设为当前工作目录，然后创建链接。
|
||||
|
||||
```
|
||||
cd ~/rpmbuild/SPECS/
|
||||
ln -s ~/development/spec/utils.spec
|
||||
```
|
||||
|
||||
运行以下命令以构建 rpm 。 如果没有错误发生，只需要花一点时间来创建 rpm 。
|
||||
|
||||
```
|
||||
rpmbuild --target noarch -bb utils.spec
|
||||
```
|
||||
|
||||
检查 ~/rpmbuild/RPMS/noarch 目录以验证新的 rpm 是否存在。
|
||||
|
||||
```
|
||||
[student@testvm1 ~]$ cd rpmbuild/RPMS/noarch/
|
||||
[student@testvm1 noarch]$ ll
|
||||
total 24
|
||||
-rw-rw-r--. 1 student student 24364 Aug 30 10:00 utils-1.0.0-1.noarch.rpm
|
||||
[student@testvm1 noarch]$
|
||||
```
|
||||
|
||||
### 测试 rpm
|
||||
|
||||
以 root 用户身份安装 rpm 以验证它是否正确安装并且文件是否安装在正确的目录中。 rpm 的确切名称将取决于你在 Preamble 部分中标签的值，但如果你使用了示例中的值，则 rpm 名称将如下面的示例命令所示：
|
||||
|
||||
```
|
||||
[root@testvm1 ~]# cd /home/student/rpmbuild/RPMS/noarch/
|
||||
[root@testvm1 noarch]# ll
|
||||
total 24
|
||||
-rw-rw-r--. 1 student student 24364 Aug 30 10:00 utils-1.0.0-1.noarch.rpm
|
||||
[root@testvm1 noarch]# rpm -ivh utils-1.0.0-1.noarch.rpm
|
||||
Preparing... ################################# [100%]
|
||||
Updating / installing...
|
||||
1:utils-1.0.0-1 ################################# [100%]
|
||||
```
|
||||
|
||||
检查 /usr/local/bin 以确保新文件存在。 你还应验证是否已创建 /etc/cron.daily 中的 create_motd 链接。
|
||||
|
||||
使用 `rpm -q --changelog utils` 命令查看更改日志。 使用 `rpm -ql utils` 命令（在 `ql`中为小写 L ）查看程序包安装的文件。
|
||||
|
||||
```
|
||||
[root@testvm1 noarch]# rpm -q --changelog utils
|
||||
* Wed Aug 29 2018 Your Name <Youremail@yourdomain.com>
|
||||
- The original package includes several useful scripts. it is
|
||||
primarily intended to be used to illustrate the process of
|
||||
building an RPM.
|
||||
|
||||
[root@testvm1 noarch]# rpm -ql utils
|
||||
/usr/local/bin/create_motd
|
||||
/usr/local/bin/die
|
||||
/usr/local/bin/mymotd
|
||||
/usr/local/bin/sysdata
|
||||
/usr/local/share/utils/Copyright.and.GPL.Notice.txt
|
||||
/usr/local/share/utils/GPL_LICENSE.txt
|
||||
/usr/local/share/utils/utils.spec
|
||||
[root@testvm1 noarch]#
|
||||
```
|
||||
|
||||
删除包。
|
||||
|
||||
```
|
||||
rpm -e utils
|
||||
```
|
||||
|
||||
### 试验
|
||||
|
||||
现在，你将更改 spec 文件以要求一个不存在的包。 这将模拟无法满足的依赖关系。 在现有依赖行下立即添加以下行：
|
||||
|
||||
```
|
||||
Requires: badrequire
|
||||
```
|
||||
|
||||
构建包并尝试安装它。 显示什么消息？
|
||||
|
||||
我们使用 `rpm` 命令来安装和删除 `utils` 包。 尝试使用 yum 或 DNF 安装软件包。 你必须与程序包位于同一目录中，或指定程序包的完整路径才能使其正常工作。
|
||||
|
||||
### 总结
|
||||
|
||||
在这里看一下创建 rpm 包的基础知识，我们没有涉及很多标签和很多部分。 下面列出的资源可以提供更多信息。 构建 rpm 包并不困难；你只需要正确的信息。 我希望这对你有所帮助——我花了几个月的时间来自己解决问题。
|
||||
|
||||
我们没有涵盖源代码构建，但如果你是开发人员，那么从这一点开始应该是一个简单的步骤。
|
||||
|
||||
创建 rpm 包是另一种成为懒惰系统管理员的好方法，可以节省时间和精力。 它提供了一种简单的方法来分发和安装那些我们作为系统管理员需要在许多主机上安装的脚本和其他文件。
|
||||
|
||||
### 资料
|
||||
|
||||
- Edward C. Baily，Maximum RPM，Sams著，于2000年，ISBN 0-672-31105-4
|
||||
- Edward C. Baily，[Maximum RPM][1]，更新在线版本
|
||||
- [RPM文档][4]：此网页列出了 rpm 的大多数可用在线文档。 它包括许多其他网站的链接和有关 rpm 的信息。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/18/9/how-build-rpm-packages
|
||||
|
||||
作者：[David Both][a]
|
||||
选题：[lujun9972](https://github.com/lujun9972)
|
||||
译者：[Flowsnow](https://github.com/Flowsnow)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/dboth
|
||||
[1]: http://ftp.rpm.org/max-rpm/
|
||||
[2]: http://rpm.org/index.html
|
||||
[3]: http://www.both.org/?p=960
|
||||
[4]: http://rpm.org/documentation.html
|
||||
@ -1,24 +1,25 @@
|
||||
在 Linux 命令行中使用 ls 列出文件的提示
|
||||
======
|
||||
学习一些 Linux "ls" 命令最有用的变化。
|
||||
|
||||
学习一些 Linux `ls` 命令最有用的变化。
|
||||
|
||||
|
||||
|
||||
我在 Linux 中最先学到的命令之一就是 `ls`。了解系统中文件所在目录中的内容非常重要。能够查看和修改不仅仅是一些文件还要所有文件也很重要。
|
||||
我在 Linux 中最先学到的命令之一就是 `ls`。了解系统中文件所在目录中的内容非常重要。能够查看和修改不仅仅是一些文件还有所有文件也很重要。
|
||||
|
||||
我的第一个 Linux 备忘录是[单页 Linux 手册][1]，它于 1999 年发布，它成为我的首选参考资料。当我开始探索 Linux 时，我把它贴在桌子上并经常参考它。它的第一页第一列的底部有使用 `ls -l` 列出文件的命令。
|
||||
我的第一个 Linux 备忘录是[单页 Linux 手册][1]，它于 1999 年发布，成了我的首选参考资料。当我开始探索 Linux 时，我把它贴在桌子上并经常参考它。它在第一页第一列的底部介绍了 `ls -l` 列出文件的命令。
|
||||
|
||||
之后，我将学习这个最基本命令的其他迭代。通过 `ls` 命令，我开始了解 Linux 文件权限的复杂性以及哪些是我的文件，哪些需要 root 或者 root 权限来修改。随着时间的推移，我习惯使用命令行，虽然我仍然使用 `ls -l` 来查找目录中的文件，但我经常使用 `ls -al`，这样我就可以看到可能需要更改的隐藏文件，比如那些配置文件。
|
||||
之后，我将学习这个最基本命令的其它迭代。通过 `ls` 命令，我开始了解 Linux 文件权限的复杂性，以及哪些是我的文件，哪些需要 root 或者 sudo 权限来修改。随着时间的推移，我习惯了使用命令行，虽然我仍然使用 `ls -l` 来查找目录中的文件，但我经常使用 `ls -al`，这样我就可以看到可能需要更改的隐藏文件，比如那些配置文件。
|
||||
|
||||
根据 Eric Fischer 在[Linux 文档项目][2]中关于 `ls` 命令的文章，该命令的根源可以追溯到 1961年 MIT 的相容分时系统 （CTSS
|
||||
） 上的 `listf` 命令。当 CTSS 被 [Multics][3] 代替时，命令变为 `list`，并有像 `list -all` 的开关。根据[维基百科][4]，“ls” 出现在 AT&T Unix 的原始版本中。我们今天在 Linux 系统上使用的 `ls` 命令来自 [GNU Core Utilities][5]。
|
||||
根据 Eric Fischer 在 [Linux 文档项目][2]中关于 `ls` 命令的文章，该命令的起源可以追溯到 1961 年 MIT 的<ruby>相容分时系统<rt>Compatible Time-Sharing System</rt></ruby>（CTSS）上的 `listf` 命令。当 CTSS 被 [Multics][3] 代替时，命令变为 `list`，并有像 `list -all` 的开关。根据[维基百科][4]，`ls` 出现在 AT&T Unix 的原始版本中。我们今天在 Linux 系统上使用的 `ls` 命令来自 [GNU Core Utilities][5]。
|
||||
|
||||
大多数时候，我只使用几个迭代的命令。使用 `ls` 或 `ls -al` 查看目录内部是我通常使用该命令的方法，但是你还应该熟悉许多其他选项。
|
||||
大多数时候，我只使用几个迭代的命令。我通常用 `ls` 或 `ls -al` 查看目录内容，但是你还应该熟悉许多其它选项。
|
||||
|
||||
`$ ls -l` 提供了一个简单的目录列表：
|
||||
`ls -l` 提供了一个简单的目录列表：
|
||||
|
||||
|
||||
|
||||
使用我的 Fedora 28 系统中的手册页，我发现 `ls` 还有许多其他选项，所有这些选项都提供了有关 Linux 文件系统的有趣且有用的信息。通过在命令提示符下输入 `man ls`，我们可以开始探索其他一些选项：
|
||||
在我的 Fedora 28 系统的手册页中，我发现 `ls` 还有许多其它选项，所有这些选项都提供了有关 Linux 文件系统的有趣且有用的信息。通过在命令提示符下输入 `man ls`，我们可以开始探索其它一些选项：
|
||||
|
||||
|
||||
|
||||
@ -38,18 +39,16 @@
|
||||
|
||||
|
||||
|
||||
以下是我认为有用且有趣的一些其他选项：
|
||||
以下是我认为有用且有趣的一些其它选项：
|
||||
|
||||
* 仅列出目录中的 .txt 文件：`ls * .txt`
|
||||
* 按文件大小列出：`ls -s`
|
||||
* 按时间和日期排序：`ls -d`
|
||||
* 按扩展名排序：`ls -X`
|
||||
* 按文件大小排序：`ls -S`
|
||||
* 带有文件大小的长格式：`ls -ls`
|
||||
* 仅列出目录中的 .txt 文件：`ls *.txt`
|
||||
* 按文件大小列出：`ls -s`
|
||||
* 按时间和日期排序：`ls -t`
|
||||
* 按扩展名排序：`ls -X`
|
||||
* 按文件大小排序：`ls -S`
|
||||
* 带有文件大小的长格式：`ls -ls`
|
||||
|
||||
|
||||
|
||||
要生成指定格式的目录列表并将其定向到文件供以后查看，请输入 `ls -al> mydirectorylist`。最后，我找到的一个更奇特的命令是 `ls -R`，它提供了计算机上所有目录及其内容的递归列表。
|
||||
要生成指定格式的目录列表并将其定向到文件供以后查看，请输入 `ls -al > mydirectorylist`。最后，我找到的一个更奇特的命令是 `ls -R`，它提供了计算机上所有目录及其内容的递归列表。
|
||||
|
||||
有关 `ls` 命令的所有迭代的完整列表，请参阅 [GNU Core Utilities][6]。
|
||||
|
||||
@ -60,7 +59,7 @@ via: https://opensource.com/article/18/10/ls-command
|
||||
作者：[Don Watkins][a]
|
||||
选题：[lujun9972](https://github.com/lujun9972)
|
||||
译者：[geekpi](https://github.com/geekpi)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
校对：[pityonline](https://github.com/pityonline)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
|
||||
@ -0,0 +1,72 @@
|
||||
如何在 Arch Linux（UEFI）上安装 GRUB
|
||||
======
|
||||
|
||||
|
||||
|
||||
前段时间，我写了一篇在安装 Windows 后在 Arch Linux 上**[如何重新安装 Grub][1]的教程。**
|
||||
|
||||
几周前，我不得不在我的笔记本上从头开始重新安装 **Arch Linux**，同时我发现安装 **Grub** 并不像我想的那么简单。
|
||||
|
||||
出于这个原因，由于在新安装 **Arch Linux** 时**在 UEFI bios 中安装 Grub** 并不容易，所以我要写这篇教程。
|
||||
|
||||
### 定位 EFI 分区
|
||||
|
||||
在 **Arch Linux** 上安装 **Grub** 的第一件重要事情是定位 **EFI** 分区。让我们运行以下命令以找到此分区：
|
||||
|
||||
```
|
||||
# fdisk -l
|
||||
```
|
||||
|
||||
我们需要检查标记为 **EFI System** 的分区，我这里是 **/dev/sda2**。
|
||||
|
||||
之后，我们需要在例如 /boot/efi 上挂载这个分区：
|
||||
|
||||
```
|
||||
# mkdir /boot/efi
|
||||
# mount /dev/sdb2 /boot/efi
|
||||
```
|
||||
|
||||
另一件重要的事情是将此分区添加到 **/etc/fstab** 中。
|
||||
|
||||
#### 安装 Grub
|
||||
|
||||
现在我们可以在我们的系统中安装 Grub：
|
||||
|
||||
```
|
||||
# grub-mkconfig -o /boot/grub/grub.cfg
|
||||
# grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=GRUB
|
||||
```
|
||||
|
||||
#### 自动将 Windows 添加到 Grub 菜单中
|
||||
|
||||
为了自动将**Windows 条目添加到 Grub 菜单**，我们需要安装 **os-prober**：
|
||||
|
||||
```
|
||||
# pacman -Sy os-prober
|
||||
```
|
||||
|
||||
要添加它，让我们运行以下命令：
|
||||
|
||||
```
|
||||
# os-prober
|
||||
# grub-mkconfig -o /boot/grub/grub.cfg
|
||||
# grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=GRUB
|
||||
```
|
||||
|
||||
你可以在[这里][2]找到更多关于在 Arch Linux 上 Grub 的信息。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://fasterland.net/how-to-install-grub-on-arch-linux-uefi.html
|
||||
|
||||
作者：[Francesco Mondello][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[geekpi](https://github.com/geekpi)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: http://fasterland.net/
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: http://fasterland.net/reinstall-grub-arch-linux.html
|
||||
[2]: https://wiki.archlinux.org/index.php/GRUB
|
||||
@ -0,0 +1,151 @@
|
||||
在 Linux 手册页中查看整个 Arch Linux Wiki
|
||||
======
|
||||
|
||||
|
||||
不久之前，我写了篇关于一个名叫 [**arch-wiki-cli**][1] 的命令行脚本的文章，使用它可以在终端命令行中查看整个 Arch Linux Wiki。使用这个脚本，你可以很轻松的用你喜欢的文本浏览器查看整个 Arch Wiki。显然，使用这个脚本需要你有一个好的网络环境。我今天偶然发现了一个名为 **Arch-wiki-man** 的程序，与其有着相同的功能。就跟名字说的一样，它可以让你在命令行查看 Arch Wiki，但是无需联网。它可以以手册页的形式为你显示来自 Arch Wiki 的任何文章。它会下载整个 Arch Wiki，并每两天自动推送一次。因此，你的系统上总能有一份 Arch Wiki 最新的复印件。
|
||||
|
||||
### 安装 Arch-wiki-man
|
||||
|
||||
Arch-wiki-man 在 [**AUR**][2] 中可用，所以你可以通过类似[**Yay**][3] 的 AUR 帮助程序安装它。
|
||||
|
||||
```
|
||||
$ yay -S arch-wiki-man
|
||||
```
|
||||
|
||||
另外，它也可以使用 NPM 安装。首先确保你已经[**安装了 NoodJS**][4]，然后使用以下命令安装它。
|
||||
|
||||
```
|
||||
$ npm install -g arch-wiki-man
|
||||
```
|
||||
|
||||
### 以手册页的形式查看整个 Arch Wiki
|
||||
|
||||
Arch-wiki-man 的典型语法如下：
|
||||
|
||||
```
|
||||
$ awman <search-query>
|
||||
```
|
||||
|
||||
下面看一些具体的例子：
|
||||
|
||||
**搜索一个或多个匹配项**
|
||||
|
||||
只需要下面的命令，就可以搜索 [**Arch Linux 安装指南**][5]。
|
||||
|
||||
```
|
||||
$ awman Installation guide
|
||||
```
|
||||
|
||||
上面的命令将会从 Arch Wiki 中搜索所有包含 “安装指南” 的条目。如果对于给出的搜索条目有很多的匹配项，将会展示为一个选择菜单。使用 **上下键** 或是 Vim 风格的方向键（**j/k**），移动到你想查看的指南上，点击回车打开。然后就会像下面这样，以手册页的形式展示指南的内容。
|
||||
|
||||
![][6]
|
||||
|
||||
awman 指的是 arch wiki man 的首字母组合。
|
||||
|
||||
它支持手册页的所有操作，所以你可以像使用手册页一样使用它。按 **h** 查看帮助选项。
|
||||
|
||||
![][7]
|
||||
|
||||
退出选择菜单不需要输入**man**，只需要按 **Ctrl+c**。
|
||||
|
||||
输入 **q** 返回或者/并且退出手册页。
|
||||
|
||||
**在标题或者概述中搜索匹配项**
|
||||
|
||||
Awman 默认只会在标题中搜索匹配项。但是你也可以指定它同时在标题和概述中搜索匹配项。
|
||||
|
||||
```
|
||||
$ awman -d vim
|
||||
```
|
||||
|
||||
或者,
|
||||
|
||||
```
|
||||
$ awman --desc-search vim
|
||||
```
|
||||
|
||||
**在目录中搜索匹配项**
|
||||
|
||||
不同于在标题和概述中搜索匹配项，它也能够扫描整个目录达到匹配的目的。不过请注意，这样将会使搜索进程明显变慢。
|
||||
|
||||
```
|
||||
$ awman -k emacs
|
||||
```
|
||||
|
||||
或者,
|
||||
|
||||
```
|
||||
$ awman --apropos emacs
|
||||
```
|
||||
|
||||
**在 web 浏览器中打开搜索结果**
|
||||
|
||||
如果你不想以手册页的形式查看 Arch Wiki 指南，你也可以像下面这样在 web 浏览器中打开它。
|
||||
|
||||
```
|
||||
$ awman -w pacman
|
||||
```
|
||||
|
||||
或者,
|
||||
|
||||
```
|
||||
$ awman --web pacman
|
||||
```
|
||||
|
||||
这条命令将会在 web 浏览器中打开匹配结果。请注意，使用这个选项需要网络连接。
|
||||
|
||||
**在其他语言中搜索**
|
||||
|
||||
Awman 默认打开的是英文的 Arch Wiki 页面。如果你想用其他的语言查看搜索结果，例如 **西班牙语**，只需要像这样做：
|
||||
|
||||
```
|
||||
$ awman -l spanish codecs
|
||||
```
|
||||
|
||||
![][8]
|
||||
|
||||
使用以下命令查看可用的语言：
|
||||
|
||||
```
|
||||
|
||||
$ awman --list-languages
|
||||
|
||||
```
|
||||
|
||||
**升级本地的 Arch Wiki复印件**
|
||||
|
||||
就像我已经说过的，更新会每两天自动推送一次。或者你也可以使用以下命令手动更新。
|
||||
|
||||
```
|
||||
$ awman-update
|
||||
arch-wiki-man@1.3.0 /usr/lib/node_modules/arch-wiki-man
|
||||
└── arch-wiki-md-repo@0.10.84
|
||||
|
||||
arch-wiki-md-repo has been successfully updated or reinstalled.
|
||||
```
|
||||
|
||||
：）
|
||||
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.ostechnix.com/how-to-browse-and-read-entire-arch-wiki-as-linux-man-pages/
|
||||
|
||||
作者：[SK][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[dianbanjiu](https://github.com/dianbanjiu)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://www.ostechnix.com/author/sk/
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://www.ostechnix.com/search-arch-wiki-website-commandline/
|
||||
[2]: https://aur.archlinux.org/packages/arch-wiki-man/
|
||||
[3]: https://www.ostechnix.com/yay-found-yet-another-reliable-aur-helper/
|
||||
[4]: https://www.ostechnix.com/install-node-js-linux/
|
||||
[5]: https://www.ostechnix.com/install-arch-linux-latest-version/
|
||||
[6]: http://www.ostechnix.com/wp-content/uploads/2018/10/awman-1.gif
|
||||
[7]: http://www.ostechnix.com/wp-content/uploads/2018/10/awman-2.png
|
||||
[8]: https://www.ostechnix.com/wp-content/uploads/2018/10/awman-3-1.png
|
||||
Loading…
Reference in New Issue
Block a user