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
f870ea98ad
67
published/20180122 Ick- a continuous integration system.md
Normal file
67
published/20180122 Ick- a continuous integration system.md
Normal file
@ -0,0 +1,67 @@
|
||||
ick：一个持续集成系统
|
||||
======
|
||||
|
||||
> ick 是一个持续集成（CI）系统。访问 <http://ick.liw.fi/> 获取更多信息。
|
||||
|
||||
更加详细的内容如下：
|
||||
|
||||
### 首个公开版本发行
|
||||
|
||||
这个世界可能并不需要又一个持续集成系统（CI），但是我需要。我对我尝试过或者看过的持续集成系统感到不满意。更重要的是，有几样我感兴趣的东西比我所听说过的持续集成系统要强大得多。因此我开始编写我自己的 CI 系统。
|
||||
|
||||
我的新个人业余项目叫做 ick。它是一个 CI 系统，这意味着它可以运行自动化的步骤来构建、测试软件。它的主页是 <http://ick.liw.fi/>，[下载][1]页面有指向源代码、.deb 包和用来安装的 Ansible 脚本的链接。
|
||||
|
||||
我现已发布了首个公开版本，绰号 ALPHA-1，版本号 0.23。（LCTT 译注：截止至本译文发布，已经更新到 ALPHA-6）它现在是 alpha 品质，这意味着它并没拥有期望的全部特性，如果任何一个它已有的特性工作的话，那真是运气好。
|
||||
|
||||
### 诚邀贡献
|
||||
|
||||
ick 目前是我的个人项目。我希望能让它不仅限于此，同时我也诚邀更多贡献。访问[治理][2]页面查看章程，[入门][3]页面查看如何开始贡献的的小建议，[联系][4]页面查看如何联络。
|
||||
|
||||
### 架构
|
||||
|
||||
ick 拥有一个由几个通过 HTTPS 协议通信使用 RESTful API 和 JSON 处理结构化数据的部分组成的架构。访问[架构][5]页面了解细节。
|
||||
|
||||
### 宣告
|
||||
|
||||
持续集成（CI）是用于软件开发的强大工具。它不应枯燥、易溃或恼人。它构建起来应简单快速，除非正在测试、构建的代码中有问题，不然它应在后台安静地工作。
|
||||
|
||||
一个持续集成系统应该简单、易用、清楚、干净、可扩展、快速、综合、透明、可靠，并推动你的生产力。构建它不应花大力气、不应需要专门为 CI 而造的硬件、不应需要频繁留意以使其保持工作、开发者永远不必思考为什么某样东西不工作。
|
||||
|
||||
一个持续集成系统应该足够灵活以适应你的构建、测试需求。只要 CPU 架构和操作系统版本没问题，它应该支持各种操作者。
|
||||
|
||||
同时像所有软件一样，CI 应该彻彻底底的免费，你的 CI 应由你做主。
|
||||
|
||||
（目前的 ick 仅稍具雏形，但是它会尝试着有朝一日变得完美 —— 在最理想的情况下。）
|
||||
|
||||
### 未来的梦想
|
||||
|
||||
长远来看，我希望 ick 拥有像下面所描述的特性。落实全部特性可能需要一些时间。
|
||||
|
||||
* 各种事件都可以触发构建。时间是一个明显的事件，因为项目的源代码仓库改变了。更强大的是任何依赖的改变，不管依赖是来自于 ick 构建的另一个项目，或者是包（比如说来自 Debian）：ick 应当跟踪所有安装进一个项目构建环境中的包，如果任何一个包的版本改变，都应再次触发项目构建和测试。
|
||||
* ick 应该支持构建于（或针对）任何合理的目标平台，包括任何 Linux 发行版，任何自由的操作系统，以及任何一息尚存的不自由的操作系统。
|
||||
* ick 应该自己管理构建环境，并且能够执行与构建主机或网络隔离的构建。这部分工作：可以要求 ick 构建容器并在容器中运行构建。容器使用 systemd-nspawn 实现。 然而，这可以改进。（如果您认为 Docker 是唯一的出路，请为此提供支持。）
|
||||
* ick 应当不需要安装任何专门的代理，就能支持各种它能够通过 ssh 或者串口或者其它这种中性的交流管道控制的<ruby>操作者<rt>worker</rt></ruby>。ick 不应默认它可以有比如说一个完整的 Java Runtime，如此一来，操作者就可以是一个微控制器了。
|
||||
* ick 应当能轻松掌控一大批项目。我觉得不管一个新的 Debian 源包何时上传，ick 都应该要能够跟得上在 Debian 中构建所有东西的进度。（明显这可行与否取决于是否有足够的资源确实用在构建上，但是 ick 自己不应有瓶颈。）
|
||||
* 如果有需要的话 ick 应当有选择性地补给操作者。如果所有特定种类的操作者处于忙碌中，且 ick 被设置成允许使用更多资源的话，它就应该这么做。这看起来用虚拟机、容器、云提供商等做可能会简单一些。
|
||||
* ick 应当灵活提醒感兴趣的团体，特别是关于其失败的方面。它应允许感兴趣的团体通过 IRC、Matrix、Mastodon、Twitter、email、SMS 甚至电话和语音合成来接受通知。例如“您好，感兴趣的团体。现在是四点钟您想被通知 hello 包什么时候为 RISC-V 构建好。”
|
||||
|
||||
### 请提供反馈
|
||||
|
||||
如果你尝试过 ick 或者甚至你仅仅是读到这，请在上面分享你的想法。在[联系][4]页面查看如何发送反馈。相比私下反馈我更偏爱公开反馈。但如果你偏爱私下反馈，那也行。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://blog.liw.fi/posts/2018/01/22/ick_a_continuous_integration_system/
|
||||
|
||||
作者：[Lars Wirzenius][a]
|
||||
译者：[tomjlw](https://github.com/tomjlw)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://blog.liw.fi/
|
||||
[1]:http://ick.liw.fi/download/
|
||||
[2]:http://ick.liw.fi/governance/
|
||||
[3]:http://ick.liw.fi/getting-started/
|
||||
[4]:http://ick.liw.fi/contact/
|
||||
[5]:http://ick.liw.fi/architecture/
|
||||
@ -1,21 +1,22 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (geekpi)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: reviewer: (wxy)
|
||||
[#]: publisher: (wxy)
|
||||
[#]: url: (https://linux.cn/article-10579-1.html)
|
||||
[#]: subject: (Mind map yourself using FreeMind and Fedora)
|
||||
[#]: via: (https://fedoramagazine.org/mind-map-yourself-using-freemind-and-fedora/)
|
||||
[#]: author: (Paul W. Frields https://fedoramagazine.org/author/pfrields/)
|
||||
|
||||
在 Fedora 中使用 FreeMind 制作自己的思维导图
|
||||
在 Fedora 中使用 FreeMind 介绍你自己
|
||||
======
|
||||
|
||||
|
||||
|
||||
你自己的思维导图一开始听起来有些牵强。它是关于神经通路么？还是心灵感应？完全不是。相反，自己的思维导图是一种在视觉上向他人描述自己的方式。它还展示了你拿来描述的特征之间的联系。这是一种以聪明的同时可控的与他人分享信息的有用方式。你可以使用任何思维导图应用来做到。本文向你展示如何使用 Fedora 中提供的 [FreeMind][1]。
|
||||
介绍你自己的思维导图，一开始听起来有些牵强。它是关于神经通路么？还是心灵感应？完全不是。相反，自己的思维导图是一种在视觉上向他人描述自己的方式。它还展示了你拿来描述自己的特征之间的联系。这是一种以聪明又同时可控的与他人分享信息的有用方式。你可以使用任何思维导图应用来做到。本文向你展示如何使用 Fedora 中提供的 [FreeMind][1]。
|
||||
|
||||
### 获取应用
|
||||
|
||||
FreeMind 已经出现有一段时间了。虽然 UI 有点过时，你也可以使用新的，但它是一个功能强大的应用，提供了许多构建思维导图的选项。当然，它是 100％ 开源的。还有其他思维导图应用可供 Fedora 和 Linux 用户使用。查看[此前一篇涵盖多个思维导图选择的文章][2]。
|
||||
FreeMind 已经出现有一段时间了。虽然 UI 有点过时，应该做一些更新了，但它是一个功能强大的应用，提供了许多构建思维导图的选项。当然，它是 100％ 开源的。还有其他思维导图应用可供 Fedora 和 Linux 用户使用。查看[此前一篇涵盖多个思维导图选择的文章][2]。
|
||||
|
||||
如果你运行的是 Fedora Workstation，请使用“软件”应用从 Fedora 仓库安装 FreeMind。或者在终端中使用这个 [sudo][3] 命令：
|
||||
|
||||
@ -26,31 +27,34 @@ $ sudo dnf install freemind
|
||||
你可以从 Fedora Workstation 中的 GNOME Shell Overview 启动应用。或者使用桌面环境提供的应用启动服务。默认情况下，FreeMind 会显示一个新的空白脑图：
|
||||
|
||||
![][4]
|
||||
FreeMind 初始（空白）思维导图
|
||||
|
||||
*FreeMind 初始（空白）思维导图*
|
||||
|
||||
脑图由链接的项目或描述（节点）组成。当你想到与节点相关的内容时，只需创建一个与其连接的新节点即可。
|
||||
|
||||
###
|
||||
### 做你自己的脑图
|
||||
|
||||
单击初始节点。编辑文本并点击**回车**将其替换为你的姓名。你就能开始你的思维导图。
|
||||
单击初始节点。编辑文本并按回车将其替换为你的姓名。你就能开始你的思维导图。
|
||||
|
||||
如果你必须向某人充分描述自己，你会怎么想？可能会有很多东西。你平时做什么？你喜欢什么？你不喜欢什么？你有什么价值？你有家庭吗？所有这些都可以在节点中体现。
|
||||
|
||||
要添加节点连接，请选择现有节点，然后单击**插入**，或使用“灯泡”图标作为新的子节点。要在与新子级相同的层级添加另一个节点，请使用**回车**。
|
||||
要添加节点连接，请选择现有节点，然后单击“Insert”，或使用“灯泡”图标作为新的子节点。要在与新子级相同的层级添加另一个节点，请使用回车。
|
||||
|
||||
如果你弄错了，别担心。你可以使用 **Delete** 键删除不需要的节点。内容上没有规则。但是最好是短节点。它们能让你在创建导图时思维更快。简洁的节点还能让其他浏览者更轻松地查看和理解。
|
||||
如果你弄错了，别担心。你可以使用 `Delete` 键删除不需要的节点。内容上没有规则。但是最好是短节点。它们能让你在创建导图时思维更快。简洁的节点还能让其他浏览者更轻松地查看和理解。
|
||||
|
||||
该示例使用节点规划了每个主要类别：
|
||||
|
||||
![][5]
|
||||
个人思维导图，第一级
|
||||
|
||||
*个人思维导图，第一级*
|
||||
|
||||
你可以为这些区域中的每个区域另外迭代一次。让你的思想自由地连接想法以生成导图。不要担心“做得正确“。最好将所有内容从头脑中移到显示屏上。这是下一级导图的样子。
|
||||
|
||||
![][6]
|
||||
个人思维导图，第二级
|
||||
|
||||
你可以以相同的方式扩展任何这些节点。请注意你在示例中可以了解多少有关 John Q. Public 的信息。
|
||||
*个人思维导图，第二级*
|
||||
|
||||
你可以以相同的方式扩展任何这些节点。请注意你在示例中可以了解多少有关 “John Q. Public” 的信息。
|
||||
|
||||
### 如何使用你的个人思维导图
|
||||
|
||||
@ -59,7 +63,6 @@ FreeMind 初始（空白）思维导图
|
||||
祝你在探索个人思维导图上玩得开心！
|
||||
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://fedoramagazine.org/mind-map-yourself-using-freemind-and-fedora/
|
||||
@ -67,7 +70,7 @@ via: https://fedoramagazine.org/mind-map-yourself-using-freemind-and-fedora/
|
||||
作者：[Paul W. Frields][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[geekpi](https://github.com/geekpi)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
@ -0,0 +1,124 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (An-DJ)
|
||||
[#]: reviewer: (wxy)
|
||||
[#]: publisher: (wxy)
|
||||
[#]: url: (https://linux.cn/article-10580-1.html)
|
||||
[#]: subject: (How to Change User Password in Ubuntu [Beginner’s Tutorial])
|
||||
[#]: via: (https://itsfoss.com/change-password-ubuntu)
|
||||
[#]: author: (Abhishek Prakash https://itsfoss.com/author/abhishek/)
|
||||
|
||||
新手教程：Ubuntu 下如何修改用户密码
|
||||
======
|
||||
|
||||
> 想要在 Ubuntu 下修改 root 用户的密码？那我们来学习下如何在 Ubuntu Linux 下修改任意用户的密码。我们会讨论在终端下修改和在图形界面（GUI）修改两种做法。
|
||||
|
||||
那么，在 Ubuntu 下什么时候会需要修改密码呢？这里我给出如下两种场景。
|
||||
|
||||
- 当你刚安装 [Ubuntu][1] 系统时，你会创建一个用户并且为之设置一个密码。这个初始密码可能安全性较弱或者太过于复杂，你会想要对它做出修改。
|
||||
- 如果你是系统管理员，你可能需要去修改在你管理的系统内其他用户的密码。
|
||||
|
||||
当然，你可能会有其他的一些原因做这样的一件事。不过现在问题来了，我们到底如何在 Ubuntu 或其它 Linux 系统下修改单个用户的密码呢？
|
||||
|
||||
在这个快速教程中，我将会展示给你在 Ubuntu 中如何使用命令行和图形界面（GUI）两种方式修改密码。
|
||||
|
||||
### 在 Ubuntu 中修改用户密码 —— 通过命令行
|
||||
|
||||
![如何在 Ubuntu Linux 下修改用户密码][2]
|
||||
|
||||
在 Ubuntu 下修改用户密码其实非常简单。事实上，在任何 Linux 发行版上修改的方式都是一样的，因为你要使用的是叫做 `passwd` 的普通 Linux 命令来达到此目的。
|
||||
|
||||
如果你想要修改你的当前密码，只需要简单地在终端执行此命令：
|
||||
|
||||
```
|
||||
passwd
|
||||
```
|
||||
|
||||
系统会要求你输入当前密码和两次新的密码。
|
||||
|
||||
在键入密码时，你不会从屏幕上看到任何东西。这在 UNIX 和 Linux 系统中是非常正常的表现。
|
||||
|
||||
```
|
||||
passwd
|
||||
Changing password for abhishek.
|
||||
(current) UNIX password:
|
||||
Enter new UNIX password:
|
||||
Retype new UNIX password:
|
||||
passwd: password updated successfully
|
||||
```
|
||||
|
||||
由于这是你的管理员账户，你刚刚修改了 Ubuntu 下 sudo 密码，但你甚至没有意识到这个操作。（LCTT 译注：执行 sudo 操作时，输入的是的用户自身的密码，此处修改的就是自身的密码。而所说的“管理员账户”指的是该用户处于可以执行 `sudo` 命令的用户组中。本文此处描述易引起误会，特注明。）
|
||||
|
||||
![在 Linux 命令行中修改用户密码][3]
|
||||
|
||||
如果你想要修改其他用户的密码，你也可以使用 `passwd` 命令来做。但是在这种情况下，你将不得不使用`sudo`。（LCTT 译注：此处执行 `sudo`，要先输入你的 sudo 密码 —— 如上提示已经修改，再输入给其它用户设置的新密码 —— 两次。）
|
||||
|
||||
```
|
||||
sudo passwd <user_name>
|
||||
```
|
||||
|
||||
如果你对密码已经做出了修改，不过之后忘记了，不要担心。你可以[很容易地在Ubuntu下重置密码][4].
|
||||
|
||||
### 修改 Ubuntu 下 root 用户密码
|
||||
|
||||
默认情况下，Ubuntu 中 root 用户是没有密码的。不必惊讶，你并不是在 Ubuntu 下一直使用 root 用户。不太懂？让我快速地给你解释下。
|
||||
|
||||
当[安装 Ubuntu][5] 时，你会被强制创建一个用户。这个用户拥有管理员访问权限。这个管理员用户可以通过 `sudo` 命令获得 root 访问权限。但是，该用户使用的是自身的密码，而不是 root 账户的密码（因为就没有）。
|
||||
|
||||
你可以使用 `passwd` 命令来设置或修改 root 用户的密码。然而，在大多数情况下，你并不需要它，而且你不应该去做这样的事。
|
||||
|
||||
你将必须使用 `sudo` 命令（对于拥有管理员权限的账户）。~~如果 root 用户的密码之前没有被设置，它会要求你设置。另外，你可以使用已有的 root 密码对它进行修改。~~（LCTT 译注：此处描述有误，使用 `sudo` 或直接以 root 用户执行 `passwd` 命令时，不需要输入该被改变密码的用户的当前密码。）
|
||||
|
||||
```
|
||||
sudo password root
|
||||
```
|
||||
|
||||
### 在 Ubuntu 下使用图形界面（GUI）修改密码
|
||||
|
||||
我这里使用的是 GNOME 桌面环境，Ubuntu 版本为 18.04。这些步骤对于其他的桌面环境和 Ubuntu 版本应该差别不大。
|
||||
|
||||
打开菜单（按下 `Windows`/`Super` 键）并搜索 “Settings”（设置）。
|
||||
|
||||
在 “Settings” 中，向下滚动一段距离打开进入 “Details”。
|
||||
|
||||
![在 Ubuntu GNOME Settings 中进入 Details][6]
|
||||
|
||||
在这里，点击 “Users” 获取系统下可见的所有用户。
|
||||
|
||||
![Ubuntu 下用户设置][7]
|
||||
|
||||
你可以选择任一你想要的用户，包括你的主要管理员账户。你需要先解锁用户并点击 “Password” 区域。
|
||||
|
||||
![Ubuntu 下修改用户密码][8]
|
||||
|
||||
你会被要求设置密码。如果你正在修改的是你自己的密码，你将必须也输入当前使用的密码。
|
||||
|
||||
![Ubuntu 下修改用户密码][9]
|
||||
|
||||
做好这些后，点击上面的 “Change” 按钮，这样就完成了。你已经成功地在 Ubuntu 下修改了用户密码。
|
||||
|
||||
我希望这篇快速精简的小教程能够帮助你在 Ubuntu 下修改用户密码。如果你对此还有一些问题或建议，请在下方留下评论。
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://itsfoss.com/change-password-ubuntu
|
||||
|
||||
作者：[Abhishek Prakash][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[An-DJ](https://github.com/An-DJ)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://itsfoss.com/author/abhishek/
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://www.ubuntu.com/
|
||||
[2]: https://i0.wp.com/itsfoss.com/wp-content/uploads/2019/02/change-password-ubuntu-linux.png?resize=800%2C450&ssl=1
|
||||
[3]: https://i0.wp.com/itsfoss.com/wp-content/uploads/2019/02/change-user-password-linux-1.jpg?resize=800%2C253&ssl=1
|
||||
[4]: https://itsfoss.com/how-to-hack-ubuntu-password/
|
||||
[5]: https://itsfoss.com/install-ubuntu-1404-dual-boot-mode-windows-8-81-uefi/
|
||||
[6]: https://i2.wp.com/itsfoss.com/wp-content/uploads/2019/02/change-user-password-ubuntu-gui-2.jpg?resize=800%2C484&ssl=1
|
||||
[7]: https://i1.wp.com/itsfoss.com/wp-content/uploads/2019/02/change-user-password-ubuntu-gui-3.jpg?resize=800%2C488&ssl=1
|
||||
[8]: https://i0.wp.com/itsfoss.com/wp-content/uploads/2019/02/change-user-password-ubuntu-gui-4.jpg?resize=800%2C555&ssl=1
|
||||
[9]: https://i1.wp.com/itsfoss.com/wp-content/uploads/2019/02/change-user-password-ubuntu-gui-1.jpg?ssl=1
|
||||
[10]: https://i0.wp.com/itsfoss.com/wp-content/uploads/2019/02/change-password-ubuntu-linux.png?fit=800%2C450&ssl=1
|
||||
@ -1,162 +0,0 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (Ampersands and File Descriptors in Bash)
|
||||
[#]: via: (https://www.linux.com/blog/learn/2019/2/ampersands-and-file-descriptors-bash)
|
||||
[#]: author: (Paul Brown https://www.linux.com/users/bro66)
|
||||
|
||||
Ampersands and File Descriptors in Bash
|
||||
======
|
||||
|
||||
|
||||
|
||||
In our quest to examine all the clutter (`&`, `|`, `;`, `>`, `<`, `{`, `[`, `(`, ), `]`, `}`, etc.) that is peppered throughout most chained Bash commands, [we have been taking a closer look at the ampersand symbol (`&`)][1].
|
||||
|
||||
[Last time, we saw how you can use `&` to push processes that may take a long time to complete into the background][1]. But, the &, in combination with angle brackets, can also be used to pipe output and input elsewhere.
|
||||
|
||||
In the [previous tutorials on][2] [angle brackets][3], you saw how to use `>` like this:
|
||||
|
||||
```
|
||||
ls > list.txt
|
||||
```
|
||||
|
||||
to pipe the output from `ls` to the _list.txt_ file.
|
||||
|
||||
Now we see that this is really shorthand for
|
||||
|
||||
```
|
||||
ls 1> list.txt
|
||||
```
|
||||
|
||||
And that `1`, in this context, is a file descriptor that points to the standard output (`stdout`).
|
||||
|
||||
In a similar fashion `2` points to standard error (`stderr`), and in the following command:
|
||||
|
||||
```
|
||||
ls 2> error.log
|
||||
```
|
||||
|
||||
all error messages are piped to the _error.log_ file.
|
||||
|
||||
To recap: `1>` is the standard output (`stdout`) and `2>` the standard error output (`stderr`).
|
||||
|
||||
There is a third standard file descriptor, `0<`, the standard input (`stdin`). You can see it is an input because the arrow (`<`) is pointing into the `0`, while for `1` and `2`, the arrows (`>`) are pointing outwards.
|
||||
|
||||
### What are the standard file descriptors good for?
|
||||
|
||||
If you are following this series in order, you have already used the standard output (`1>`) several times in its shorthand form: `>`.
|
||||
|
||||
Things like `stderr` (`2`) are also handy when, for example, you know that your command is going to throw an error, but what Bash informs you of is not useful and you don't need to see it. If you want to make a directory in your _home/_ directory, for example:
|
||||
|
||||
```
|
||||
mkdir newdir
|
||||
```
|
||||
|
||||
and if _newdir/_ already exists, `mkdir` will show an error. But why would you care? (Ok, there some circumstances in which you may care, but not always.) At the end of the day, _newdir_ will be there one way or another for you to fill up with stuff. You can supress the error message by pushing it into the void, which is _/dev/null_ :
|
||||
|
||||
```
|
||||
mkdir newdir 2> /dev/null
|
||||
```
|
||||
|
||||
This is not just a matter of " _let's not show ugly and irrelevant error messages because they are annoying,_ " as there may be circumstances in which an error message may cause a cascade of errors elsewhere. Say, for example, you want to find all the _.service_ files under _/etc_. You could do this:
|
||||
|
||||
```
|
||||
find /etc -iname "*.service"
|
||||
```
|
||||
|
||||
But it turns out that on most systems, many of the lines spat out by `find` show errors because a regular user does not have read access rights to some of the folders under _/etc_. It makes reading the correct output cumbersome and, if `find` is part of a larger script, it could cause the next command in line to bork.
|
||||
|
||||
Instead, you can do this:
|
||||
|
||||
```
|
||||
find /etc -iname "*.service" 2> /dev/null
|
||||
```
|
||||
|
||||
And you get only the results you are looking for.
|
||||
|
||||
### A Primer on File Descriptors
|
||||
|
||||
There are some caveats to having separate file descriptors for `stdout` and `stderr`, though. If you want to store the output in a file, doing this:
|
||||
|
||||
```
|
||||
find /etc -iname "*.service" 1> services.txt
|
||||
```
|
||||
|
||||
would work fine because `1>` means " _send standard output, and only standard output (NOT standard error) somewhere_ ".
|
||||
|
||||
But herein lies a problem: what if you *do* want to keep a record within the file of the errors along with the non-erroneous results? The instruction above won't do that because it ONLY writes the correct results from `find`, and
|
||||
|
||||
```
|
||||
find /etc -iname "*.service" 2> services.txt
|
||||
```
|
||||
|
||||
will ONLY write the errors.
|
||||
|
||||
How do we get both? Try the following command:
|
||||
|
||||
```
|
||||
find /etc -iname "*.service" &> services.txt
|
||||
```
|
||||
|
||||
... and say hello to `&` again!
|
||||
|
||||
We have been saying all along that `stdin` (`0`), `stdout` (`1`), and `stderr` (`2`) are _file descriptors_. A file descriptor is a special construct that points to a channel to a file, either for reading, or writing, or both. This comes from the old UNIX philosophy of treating everything as a file. Want to write to a device? Treat it as a file. Want to write to a socket and send data over a network? Treat it as a file. Want to read from and write to a file? Well, obviously, treat it as a file.
|
||||
|
||||
So, when managing where the output and errors from a command goes, treat the destination as a file. Hence, when you open them to read and write to them, they all get file descriptors.
|
||||
|
||||
This has interesting effects. You can, for example, pipe contents from one file descriptor to another:
|
||||
|
||||
```
|
||||
find /etc -iname "*.service" 1> services.txt 2>&1
|
||||
```
|
||||
|
||||
This pipes `stderr` to `stdout` and `stdout` is piped to a file, _services.txt_.
|
||||
|
||||
And there it is again: the `&`, signaling to Bash that `1` is the destination file descriptor.
|
||||
|
||||
Another thing with the standard file descriptors is that, when you pipe from one to another, the order in which you do this is a bit counterintuitive. Take the command above, for example. It looks like it has been written the wrong way around. You may be reading it like this: " _pipe the output to a file and then pipe errors to the standard output._ " It would seem the error output comes to late and is sent when `1` is already done.
|
||||
|
||||
But that is not how file descriptors work. A file descriptor is not a placeholder for the file, but for the _input and/or output channel_ to the file. In this case, when you do `1> services.txt`, you are saying " _open a write channel to services.txt and leave it open_ ". `1` is the name of the channel you are going to use, and it remains open until the end of the line.
|
||||
|
||||
If you still think it is the wrong way around, try this:
|
||||
|
||||
```
|
||||
find /etc -iname "*.service" 2>&1 1>services.txt
|
||||
```
|
||||
|
||||
And notice how it doesn't work; notice how errors get piped to the terminal and only the non-erroneous output (that is `stdout`) gets pushed to `services.txt`.
|
||||
|
||||
That is because Bash processes every result from `find` from left to right. Think about it like this: when Bash gets to `2>&1`, `stdout` (`1`) is still a channel that points to the terminal. If the result that `find` feeds Bash contains an error, it is popped into `2`, transferred to `1`, and, away it goes, off to the terminal!
|
||||
|
||||
Then at the end of the command, Bash sees you want to open `stdout` as a channel to the _services.txt_ file. If no error has occurred, the result goes through `1` into the file.
|
||||
|
||||
By contrast, in
|
||||
|
||||
```
|
||||
find /etc -iname "*.service" 1>services.txt 2>&1
|
||||
```
|
||||
|
||||
`1` is pointing at `services.txt` right from the beginning, so anything that pops into `2` gets piped through `1`, which is already pointing to the final resting place in `services.txt`, and that is why it works.
|
||||
|
||||
In any case, as mentioned above `&>` is shorthand for " _both standard output and standard error_ ", that is, `2>&1`.
|
||||
|
||||
This is probably all a bit much, but don't worry about it. Re-routing file descriptors here and there is commonplace in Bash command lines and scripts. And, you'll be learning more about file descriptors as we progress through this series. See you next week!
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.linux.com/blog/learn/2019/2/ampersands-and-file-descriptors-bash
|
||||
|
||||
作者：[Paul Brown][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.linux.com/users/bro66
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://www.linux.com/blog/learn/2019/2/and-ampersand-and-linux
|
||||
[2]: https://www.linux.com/blog/learn/2019/1/understanding-angle-brackets-bash
|
||||
[3]: https://www.linux.com/blog/learn/2019/1/more-about-angle-brackets-bash
|
||||
@ -1,74 +0,0 @@
|
||||
Ick：一个连续集成系统
|
||||
======
|
||||
|
||||
**TL;DR:** Ick 是一个连续集成或者 CI 系统。访问 <http://ick.liw.fi/> 获取跟多信息。
|
||||
|
||||
更加详细的版本随后会出
|
||||
|
||||
### 首个公开版本发行
|
||||
|
||||
世界可能还不需要另一个连续集成系统（CI）但是我需要。我已对我尝试过或者看过的连续集成系统感到不满意了。更重要的是，几样我感兴趣的东西比我所听说过的连续集成系统要强大得多。因此我开始编写我自己的 CI 系统。
|
||||
|
||||
我的新个人业余项目叫做 ick。它是一个 CI 系统，这意味着他可以运行自动化的步骤来搭建、测试软件。它的主页是<http://ick.liw.fi/>，[下载][1]页面有导向源码、.deb 包和用来安装的 Ansible 脚本的链接。
|
||||
|
||||
我现已发布了首个公开版本，绰号 ALPHA-1，版本号0.23。它现在是 alpha 品质，这意味着它并没拥有所有期望的特性，如果任何一个它已有的特性工作的话，你应该感到庆幸。
|
||||
|
||||
### 诚邀英才
|
||||
|
||||
Ick 目前是我的个人项目。我希望能让它不仅限于此，同时我也诚邀英才。访问[管理][2]页面查看章程，[开始][3]页面查看如何开始贡献的的小贴士，[联系][4]页面查看如何联络。
|
||||
|
||||
### 架构
|
||||
|
||||
Ick 拥有一个由几个通过 HTTPS 协议通信使用 RESTful API 和 JSON 处理结构化数据的部分组成的架构。访问[架构][5]页面查看细节。
|
||||
|
||||
### 宣言
|
||||
|
||||
连续集成（CI）是用于软件开发的强大工具。它不应枯燥、易溃或恼人。它搭建起来应简单快速，除非正在测试、搭建中的码有问题，不然它应在后台安静地工作。
|
||||
|
||||
一个连续集成系统应该简单、易用、清楚、干净、可扩展、快速、综合、透明、可靠并推动你的生产力。搭建它不应花大力气、不应需要专门为 CI 而造的硬件、不应需要频繁留意以使其保持工作、开发者永远不必思考为什么某样东西不工作。
|
||||
|
||||
一个连续集成系统应该足够灵活以适应你的搭建、测试需求。只要 CPU 架构和操作系统版本没问题，它应该支持各式操作者。
|
||||
|
||||
同时像所有软件一样，CI 应该彻彻底底的免费，你的 CI 应由你做主。
|
||||
|
||||
（目前的 Ick 仅稍具雏形，但是它会尝试着有朝一日变得完美，在最理想的情况下。）
|
||||
|
||||
### 未来的梦想
|
||||
|
||||
长远来看，我希望 ick 拥有像下面所描述的特性。落实全部特性可能需要一些时间。
|
||||
|
||||
* 多种多样的事件都可以触发搭建。时间是一个明显的事件因为项目的源代码仓库改变了。更强大的是不管依赖是来自于 ick 搭建的另一个项目或则包比如说来自 Debian，任何用于搭建的依赖都会改变：ick 应当跟踪所有安装进一个项目搭建环境中的包，如果任何一个包的版本改变，都应再次触发项目搭建和测试。
|
||||
|
||||
* Ick 应该支持搭建任何合理的目标，包括任何 Linux 发行版，任何免费的操作系统，以及任何一息尚存的收费操作系统。
|
||||
|
||||
* Ick 应当不需要安装任何专门的代理，就能支持各种它能够通过 ssh 或者串口或者其它这种中性交流管道控制的操作者。Ick 不应默认它可以有比如说一个完整的 Java Runtime，如此一来，操作者就可以是一个微控制器了。
|
||||
|
||||
* Ick 应当能轻松掌控一大批项目。我觉得不管一个新的 Debian 源包何时上传，Ick 都应该要能够跟得上在 Debian 中搭建所有东西的进度。（明显这可行与否取决于是否有足够的资源确实用在搭建上，但是 Ick 自己不应有瓶颈。）
|
||||
|
||||
* 如果有需要的话 Ick 应当有选择性地补给操作者。如果所有特定种类的操作者处于忙碌中且 Ick 被设置成允许使用更多资源的话，它就应该这么做。这看起来用虚拟机、容器、云提供商等做可能会简单一些。
|
||||
|
||||
* Ick 应当灵活提醒感兴趣的团体特别是关于其失败的方面。它应允许感兴趣的团体通过 IRC，Matrix，Mastodon， Twitter， email， SMS 甚至电话和语音合成来接受通知。例如“您好，感兴趣的团体。现在是四点钟您想被通知 hello 包什么时候为 RISC-V 搭建好。”
|
||||
|
||||
|
||||
|
||||
|
||||
### 请提供反馈
|
||||
|
||||
如果你尝试 ick 或者甚至你仅仅是读到这，请在上面分享你的想法。[联系][4]页面查看如何发送反馈。相比私下反馈我更偏爱公开反馈。但如果你偏爱私下反馈，那也行。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://blog.liw.fi/posts/2018/01/22/ick_a_continuous_integration_system/
|
||||
|
||||
作者：[Lars Wirzenius][a]
|
||||
译者：[tomjlw](https://github.com/tomjlw)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://blog.liw.fi/
|
||||
[1]:http://ick.liw.fi/download/
|
||||
[2]:http://ick.liw.fi/governance/
|
||||
[3]:http://ick.liw.fi/getting-started/
|
||||
[4]:http://ick.liw.fi/contact/
|
||||
[5]:http://ick.liw.fi/architecture/
|
||||
@ -0,0 +1,162 @@
|
||||
[#]: collector: "lujun9972"
|
||||
[#]: translator: "zero-mk "
|
||||
[#]: reviewer: " "
|
||||
[#]: publisher: " "
|
||||
[#]: url: " "
|
||||
[#]: subject: "Ampersands and File Descriptors in Bash"
|
||||
[#]: via: "https://www.linux.com/blog/learn/2019/2/ampersands-and-file-descriptors-bash"
|
||||
[#]: author: "Paul Brown https://www.linux.com/users/bro66"
|
||||
|
||||
Bash中的＆符号和文件描述符
|
||||
======
|
||||
|
||||
|
||||
|
||||
在我们寻求检查所有的clutter（`&`，`|`，`;`，`>`，`<`，`{`，`[`，`(`，） `]`，`}` 等等）是在大多数链式Bash命令中都会出现，[我们一直在仔细研究（`&`）符号][1]。
|
||||
|
||||
[上次，我们看到了如何使用`&`把可能需要很长时间运行的进程放到后台运行][1]。但是，`＆`与尖括号`<`结合使用，也可用于管道输出或向其他地方的输入。
|
||||
|
||||
在[前面的][2] [尖括号教程中][3]，您看到了如何使用`>`，如下：
|
||||
|
||||
```
|
||||
ls > list.txt
|
||||
```
|
||||
|
||||
将`ls`输出传递给_list.txt_文件。
|
||||
|
||||
现在我们看到的是简写
|
||||
|
||||
```
|
||||
ls 1> list.txt
|
||||
```
|
||||
|
||||
在这种情况下，`1`是一个文件描述符，指向标准输出（`stdout`）。
|
||||
|
||||
以类似的方式，`2`指向标准error（`stderr`）：
|
||||
|
||||
```
|
||||
ls 2> error.log
|
||||
```
|
||||
|
||||
所有错误消息都通过管道传递给_error.log_文件。
|
||||
|
||||
回顾一下：`1>`是标准输出（`stdout`），`2>`标准错误输出（`stderr`）。
|
||||
|
||||
第三个标准文件描述符，`0<`标准输入（`stdin`）。您可以看到它是一个输入，因为箭头（`<`）指向`0`，而对于 `1`和`2`，箭头（`>`）是指向外部的。
|
||||
|
||||
### 标准文件描述符有什么用？
|
||||
|
||||
如果您在阅读本系列以后，您已经多次使用标准输出（`1>`）的简写形式：`>`。
|
||||
|
||||
例如，当（假如）你知道你的命令会抛出一个错误时，像`stderr`（`2`）这样的东西也很方便，但是Bash告诉你的东西是没有用的，你不需要看到它。如果要在_home/_目录中创建目录，例如：
|
||||
|
||||
```
|
||||
mkdir newdir
|
||||
```
|
||||
|
||||
如果_newdir/_已经存在，`mkdir`将显示错误。但你为什么要关心？（好吧，在某些情况下你可能会关心，但并非总是如此。）在一天结束时，_newdir_会以某种方式让你填写一些东西。您可以通过将错误消息推入void（即_/dev/null_）来抑制错误消息：
|
||||
|
||||
```
|
||||
mkdir newdir 2> /dev/null
|
||||
```
|
||||
|
||||
这不仅仅是“ _让我们不要看到丑陋和无关的错误消息，因为它们很烦人_ ”，因为在某些情况下，错误消息可能会在其他地方引起一连串错误。比如说，你想找到_/etc_下所有的*.service_文件。你可以这样做：
|
||||
|
||||
```
|
||||
find /etc -iname "*.service"
|
||||
```
|
||||
|
||||
但事实证明，在大多数系统中，`find`显示错误会导致许多行出现问题，因为普通用户对_/etc_下的某些文件夹没有读取访问权限。它使读取正确的输出变得很麻烦，如果`find`是更大的脚本的一部分，它可能会导致行中的下一个命令排队。
|
||||
|
||||
相反，你可以这样做：
|
||||
|
||||
```
|
||||
find /etc -iname "*.service" 2> /dev/null
|
||||
```
|
||||
|
||||
而且你只得到你想要的结果。
|
||||
|
||||
### 文件描述符入门
|
||||
|
||||
单独的文件描述符`stdout`和`stderr`还有一些注意事项。如果要将输出存储在文件中，请执行以下操作：
|
||||
|
||||
```
|
||||
find /etc -iname "*.service" 1> services.txt
|
||||
```
|
||||
|
||||
工作正常，因为`1>`意味着“ _发送标准输出，只有标准输出（非标准错误）_ ”。
|
||||
|
||||
但这里存在一个问题：如果你想保留命令抛出的错误信息的和非错误信息你该怎么*做*？上面的说明并不会这样做，因为它只写入`find`正确的结果
|
||||
|
||||
```
|
||||
find /etc -iname "*.service" 2> services.txt
|
||||
```
|
||||
|
||||
只会写入命令抛出的错误信息。
|
||||
|
||||
我们如何得到两者？请尝试以下命令：
|
||||
|
||||
```
|
||||
find /etc -iname "*.service" &> services.txt
|
||||
```
|
||||
|
||||
…… 再次和`&`打招呼！
|
||||
|
||||
我们一直在说`stdin`（`0`），`stdout`（`1`）和`stderr`（`2`）是_文件描述符_。文件描述符是一种特殊构造，指向文件的通道，用于读取或写入，或两者兼而有之。这来自于将所有内容都视为文件的旧UNIX理念。想写一个设备？将其视为文件。想写入套接字并通过网络发送数据？将其视为文件。想要读取和写入文件？嗯，显然，将其视为文件。
|
||||
|
||||
因此，在管理命令的输出和错误的位置时，将目标视为文件。因此，当您打开它们来读取和写入它们时，它们都会获得文件描述符。
|
||||
|
||||
这是一个有趣的效果。例如，您可以将内容从一个文件描述符传递到另一个文件描述符：
|
||||
|
||||
```
|
||||
find /etc -iname "*.service" 1> services.txt 2>&1
|
||||
```
|
||||
|
||||
该管道`stderr`以`stdout`与`stdout`通过管道被输送到一个文件中，_services.txt的_。
|
||||
|
||||
它再次出现：`&`发信号通知Bash `1`是目标文件描述符。
|
||||
|
||||
标准文件描述符的另一个问题是，当你从一个管道传输到另一个时，你执行此操作的顺序有点违反直觉。例如，按照上面的命令。它看起来像是错误的方式。您可能正在阅读它：“ _将输出传输到文件，然后将错误传递给标准输出。_ ”看起来错误输出会很晚，并且在`1`已经完成时发送。
|
||||
|
||||
但这不是文件描述符的工作方式。文件描述符不是文件的占位符，而是文件的_输入and/or输出通道_。在这种情况下，当你`1> services.txt`这样做时，你会说“ _打开一个写管道到services.txt并保持打开状态_ ”。`1`是您要使用的管道的名称，它将保持打开状态直到该行的结尾。
|
||||
|
||||
如果你仍然认为这是错误的方法，试试这个：
|
||||
|
||||
```
|
||||
find /etc -iname "*.service" 2>&1 1>services.txt
|
||||
```
|
||||
|
||||
并注意它是如何工作的; 注意错误是如何通过管道输送到终端的，所以只有非错误的输出（即`stdout`）被推送到`services.txt`。
|
||||
|
||||
这是因为Bash从左到右处理`find`的每个结果。这样想：当Bash到达`2>&1`时，`stdout` (`1`) 仍然是指向终端的通道。如果`find` Bash的结果包含一个错误，它将被弹出到`2`，转移到`1`，然后离开终端！
|
||||
|
||||
然后在命令结束时，Bash看到您要打开`stdout`作为_services.txt_文件的通道。如果没有发生错误，结果将`1`进入文件。
|
||||
|
||||
相比之下，在
|
||||
|
||||
```
|
||||
find /etc -iname "*.service" 1>services.txt 2>&1
|
||||
```
|
||||
|
||||
`1`从一开始就指向services.txt，因此任何弹出到`2`的内容都会通过`1`进行管道传输，而`1`已经指向services.txt中的最后一个休息位置，这就是它工作的原因。在任何情况下，如上所述`&>`都是“标准输出和标准错误”的缩写，即`2>&1`。
|
||||
|
||||
在任何情况下，如上所述`&>`是“_标准输出和标准误差_”的简写，即`2>&1`。
|
||||
|
||||
这可能有点多，但不用担心。调整文件描述符在Bash命令行和脚本中是司空见惯的事。随着本系列的深入，您将了解更多关于文件描述符的知识。下周见!
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.linux.com/blog/learn/2019/2/ampersands-and-file-descriptors-bash
|
||||
|
||||
作者：[Paul Brown][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[zero-mk](https://github.com/zero-mk)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://www.linux.com/users/bro66
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://www.linux.com/blog/learn/2019/2/and-ampersand-and-linux
|
||||
[2]: https://www.linux.com/blog/learn/2019/1/understanding-angle-brackets-bash
|
||||
[3]: https://www.linux.com/blog/learn/2019/1/more-about-angle-brackets-bash
|
||||
@ -1,129 +0,0 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (An-DJ)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (How to Change User Password in Ubuntu [Beginner’s Tutorial])
|
||||
[#]: via: (https://itsfoss.com/change-password-ubuntu)
|
||||
[#]: author: (Abhishek Prakash https://itsfoss.com/author/abhishek/)
|
||||
|
||||
Ubuntu下如何修改用户密码 [新手教程]
|
||||
======
|
||||
**想要在Ubuntu下修改root用户的密码？那我们来学习下如何在Ubuntu Linux下修改任意用户的密码。我们会讨论在终端下修改和在图形界面(GUI)修改两种做法**
|
||||
|
||||
那么，在Ubuntu下什么时候会需要修改密码呢？这里我给出如下两种场景。
|
||||
|
||||
当你刚安装[Ubuntu][1]系统时，你会创建一个用户并且为之设置一个密码。这个初始密码可能安全性较弱或者太过于复杂，你会想要对它做出修改。
|
||||
|
||||
如果你是系统管理员，你可能需要去修改在你管理的系统内其他用户的密码。
|
||||
|
||||
当然，你可能会有其他的一些原因做这样的一件事。不过现在问题来了，我们到底如何在Ubuntu或Linux系统下修改单个用户的密码呢？
|
||||
|
||||
在这个快速教程中，我将会展示给你在Ubuntu中如何使用命令行和图形界面(GUI)两种方式修改密码。
|
||||
|
||||
### 在Ubuntu中修改用户密码[通过命令行]
|
||||
|
||||
![如何在Ubuntu Linux下修改用户密码][2]
|
||||
|
||||
在Ubuntu下修改用户密码其实非常简单。事实上，在任何Linux发行版上修改的方式都是一样的，因为你要使用的是叫做 passwd 的普通Linux命令来达到此目的。
|
||||
|
||||
如果你想要修改你的当前密码，只需要简单地在终端执行此命令：
|
||||
|
||||
```
|
||||
passwd
|
||||
```
|
||||
|
||||
系统会要求你输入当前密码和两次新的密码。
|
||||
|
||||
在键入密码时，你不会从屏幕上看到任何东西。这在UNIX和Linux系统中是非常正常的表现。
|
||||
|
||||
```
|
||||
passwd
|
||||
|
||||
Changing password for abhishek.
|
||||
|
||||
(current) UNIX password:
|
||||
|
||||
Enter new UNIX password:
|
||||
|
||||
Retype new UNIX password:
|
||||
|
||||
passwd: password updated successfully
|
||||
```
|
||||
|
||||
由于这是你的管理员账户，你刚刚修改了Ubuntu下sudo的密码，但你甚至没有意识到这个操作。
|
||||
|
||||
![在Linux命令行中修改用户密码][3]
|
||||
|
||||
如果你想要修改其他用户的密码，你也可以使用passwd命令来做。但是在这种情况下，你将不得不使用sudo。
|
||||
|
||||
```
|
||||
sudo passwd <user_name>
|
||||
```
|
||||
|
||||
如果你对密码已经做出了修改，不过之后忘记了，不要担心。你可以[很容易地在Ubuntu下重置密码][4].
|
||||
|
||||
### 修改Ubuntu下root用户密码
|
||||
|
||||
默认情况下，Ubuntu中root用户是没有密码的。不必惊讶，你并不是在Ubuntu下一直使用root用户。不太懂？让我快速地给你解释下。
|
||||
|
||||
当[安装Ubuntu][5]时，你会被强制创建一个用户。这个用户拥有管理员访问权限。这个管理员用户可以通过sudo命令获得root访问权限。但是，该用户使用的是自身的密码，而不是root账户的密码（因为就没有）。
|
||||
|
||||
你可以使用**passwd**命令来设置或修改root用户的密码。然而，在大多数情况下，你并不需要它，而且你不应该去做这样的事。
|
||||
|
||||
你将不得不使用sudo命令（对于拥有管理员权限的账户）。如果root用户的密码之前没有被设置，它会要求你设置。另外，你可以使用已有的root密码对它进行修改。
|
||||
|
||||
```
|
||||
sudo password root
|
||||
```
|
||||
|
||||
### 在Ubuntu下使用图形界面（GUI）修改密码
|
||||
|
||||
我这里使用的是GNOME桌面环境，Ubuntu版本为18.04。这些步骤对于其他桌面环境和Ubuntu版本应该差别不大。
|
||||
|
||||
打开菜单（按下Windows/Super键）并搜索Settings。
|
||||
|
||||
在Settings中，向下滚动一段距离打开进入Details。
|
||||
|
||||
![在Ubuntu GNOME Settings中进入Details][6]
|
||||
|
||||
在这里，点击Users获取系统下可见的所有用户。
|
||||
|
||||
![Ubuntu下用户设置][7]
|
||||
|
||||
你可以选择任一你想要的用户，包括你的主要管理员账户。你需要先解锁用户并点击密码（password）区域。
|
||||
|
||||
![Ubuntu下修改用户密码][8]
|
||||
|
||||
你会被要求设置密码。如果你正在修改的是你自己的密码，你将必须也输入当前使用的密码。
|
||||
|
||||
![Ubuntu下修改用户密码][9]
|
||||
|
||||
做好这些后，点击上面的Change按钮，这样就完成了。你已经成功地在Ubuntu下修改了用户密码。
|
||||
|
||||
我希望这篇快速精简的小教程能够帮助你在Ubuntu下修改用户密码。如果你对此还有一些问题或建议，请在下方留下评论。
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://itsfoss.com/change-password-ubuntu
|
||||
|
||||
作者：[Abhishek Prakash][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[An-DJ](https://github.com/An-DJ)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://itsfoss.com/author/abhishek/
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://www.ubuntu.com/
|
||||
[2]: https://i0.wp.com/itsfoss.com/wp-content/uploads/2019/02/change-password-ubuntu-linux.png?resize=800%2C450&ssl=1
|
||||
[3]: https://i0.wp.com/itsfoss.com/wp-content/uploads/2019/02/change-user-password-linux-1.jpg?resize=800%2C253&ssl=1
|
||||
[4]: https://itsfoss.com/how-to-hack-ubuntu-password/
|
||||
[5]: https://itsfoss.com/install-ubuntu-1404-dual-boot-mode-windows-8-81-uefi/
|
||||
[6]: https://i2.wp.com/itsfoss.com/wp-content/uploads/2019/02/change-user-password-ubuntu-gui-2.jpg?resize=800%2C484&ssl=1
|
||||
[7]: https://i1.wp.com/itsfoss.com/wp-content/uploads/2019/02/change-user-password-ubuntu-gui-3.jpg?resize=800%2C488&ssl=1
|
||||
[8]: https://i0.wp.com/itsfoss.com/wp-content/uploads/2019/02/change-user-password-ubuntu-gui-4.jpg?resize=800%2C555&ssl=1
|
||||
[9]: https://i1.wp.com/itsfoss.com/wp-content/uploads/2019/02/change-user-password-ubuntu-gui-1.jpg?ssl=1
|
||||
[10]: https://i0.wp.com/itsfoss.com/wp-content/uploads/2019/02/change-password-ubuntu-linux.png?fit=800%2C450&ssl=1
|
||||
Loading…
Reference in New Issue
Block a user