无论你在 Python 编程过程中处于什么阶段，这些 Python 热门文章将会对你有很大帮助。2019 年是 Python 的好年景。根据 GitHub 和 Stack Overflow 的受欢迎资源程度来看，它正在成为全球第二大流行语言。（LCTT 译注：原文发表于 2019 年底，但是这里提及的文章并没有过时。）“在我们的调查中，Python 作为增长最快的程序设计语言，在程序设计语言中排名再次上升，今年排在 Java 之前，成为第二大最受欢迎的程序设计语言（仅次于 Rust ）。”— Stack Overflow Insights同样，Python 的读者人数呈跳跃式激增。以下是按主题分组的 2019 年以来最热门的 Python 文章，供你仔细阅读。为什么选择 Python ？在众多的程序设计语言中，是什么使 Python 成为首选呢？从文章的阅读量来看，那就是因为它的灵活性。正如 Jigyasa Grover 解释的那样，Python 开发人员可以使用 多种范例，包括 Seth Kenlon 教程所展示的流行的 面向对象程序设计。如果你是 Python 的长期用户，并且正在寻找 Python 为什么是完美的程序设计语言的高级例子，那么可以看 Moshe Zadka 的 喜欢 Python 的 5 大理由。如果这还不够的话，你也可以使用功能强大的工具来尝试，无需编写大量代码，例如 Parul Pandey 关于 图像处理 的教程。配置 Python随着 Python 的受欢迎程度不断提高，使用它的人越来越多。这些新手中的许多人都是在 Mac 操作系统上进行的，并且正在使用 Moshe 和我写的 Python3 配置向导。安装 Python 之后，接下来就是决定利用什么工具编写代码。关于文本编辑器和集成开发环境（IDE），有很多选择，但是读者似乎更喜欢图形界面，在有关该主题的文章中，Stephan Avenwedde 的关于 Pythonic 和我关于 JupyterLab 的文章的读者最多。在对程序设计语言充满信心的途径上，开发人员将不得不面对众多选择，来管理程序设计语言的版本和项目依赖。幸运的是，László Kiss Kollár 的文章 Python 包管理 让其变得更加容易。当你准备好配置一个具有所有功能的 IDE，以最大限度地利用这门语言时，请一定尝试一下 linter Black，如 Moshe 说的，保持代码的清洁。小结无论你处在 Python 程序设计的哪个阶段，这些热门 Python 文章都将为你提供帮助。如果没有至少一次对测试重要性的认可，我无法对此进行总结，为此，Moshe 提供了另一篇 关于 tox 的好文章。via: https://opensource.com/article/19/12/learn-python作者：Matthew Broberg 选题：lujun9972 译者：stevenzdg988 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
想学习 Git？看看这个最重要的术语和命令的快速总结。如今，对于任何希望跟踪他们的变化的人来说，版本控制是一个重要的工具。它对程序员、系统管理员和 网站可靠性工程师 site reliability engineers （SRE）都特别有用。确保可以从错误中恢复到已知的良好状态是一个巨大的胜利，比以前给复制的文件添加 .old 后缀的策略更友好。但学习 Git 这件事往往被告诉大家“投身开源”的好心同行们过度简化了。在你还不明白之前，就有人要你给一个从 上游 upstream 变基 rebase 的 拉取请求 pull request （PR）或 合并请求 merge request （MR），然后他们才能从你的 远程版本库 remote 合并 —— 而且一定会删除 合并提交 merge commits 。无论你想给开源项目做出什么好的贡献，当你看到这些你不认识的单词时，都会觉得难以融入。下载 我们的 Git 速查表。如果你有一两个月的时间和足够的好奇心，Git SCM 是你需要学习所有术语的权威来源。但如果你正在寻找来自实践的总结，请继续阅读。提交就是提醒对我来说，Git 最难理解的部分是 Git 最简单的概念：一个 提交 commit 就是一个内容的集合，包括一个关于描述的信息，以及之前的提交。没有固有的代码发布策略，甚至没有内置的明确建议。这个内容甚至不一定是代码 —— 可以是任何你想添加到版本库的东西。 提交消息 commit message 会对这些内容进行注释。我喜欢把提交信息看作是给未来的自己的礼物：它可能会提到你编辑的文件，但更重要的是它提醒你修改这些文件的意图。添加更多关于你为什么编辑这些内容的信息，可以帮助任何使用你的版本库的人，即使那个人是你。origin/master 在哪里？要知道自己在 Git 项目中的位置，首先把它想成一棵树。所有 Git 项目都有一个根目录，类似于文件系统的根目录。所有的提交都是这个根目录下的分支。这样一来，分支只是一个提交的指针。按照惯例，master 是根目录下默认的分支名称。（LCTT 译注：世界变得快，原文发表于 2019 年，而现在有些地方开始用 main 替代这个名字。）由于 Git 是一个分布式的版本控制系统，同一个代码库分布在多个地方，所以人们经常用 版本库 repository 这个词来表示同一个项目的所有副本。（LCTT 译注：“repository” 英文原意是仓库、存储库，在计算机环境中，常用于版本控制、软件分发等方面，有时候会统一译作“仓库”、“存储库”。但我们认为，应该根据不同语境采用更有指向性的译法。在 Git 等版本控制语境中，采用“版本库”；在软件分发方面，采用“软件库”；其它泛指或不确定的语境中，可采用“仓库”、“存储库”译法。）有 本地版本库 local repository ，这是你编辑代码的地方（稍后会有更多的介绍），还有 远程版本库 remote repository ，这是你完成后想把代码发送到的地方。远程版本库可以在任何地方，甚至在你的本地版本库所在的同一台计算机上，但它们通常托管在 GitLab 或 GitHub 等版本库服务上。我在哪里？虽然不是官方的卖点，但迷路也是 Git 仓库的“乐趣”之一。你可以通过这套可靠的命令来找到自己的方向：git branch —— 找到你所在的分支。git log —— 查看你正在进行的提交。git status —— 查看自上次提交以来你所做的编辑。git remote —— 查看你正在跟踪的远程仓库。用这些命令来定位自己的方向，当你被卡住的时候，会让你有一种方向感。我是否已将我的提交暂存或缓存起来？你电脑上的代码俗称为你的 工作空间 workspace 。但不是很明显的是，当你在 Git 仓库中时，你还有两个（是的，两个！）其他位置： 索引 index 和 暂存 stash 。当你写了一些内容，然后添加时，你是把它添加到索引中，也就是准备提交的缓存内容。有的时候，你的索引中的文件还没有准备好提交，但你想查看另一个分支。这时，暂存就派上用场了。你可以使用 git stash 将索引了但尚未提交的文件存储到暂存区中。当你准备好取回文件时，运行 git stash pop 将更改带回索引中。下面是一些你需要使用暂存区和缓存区的命令：git diff ...origin/master —— 显示最近的本地提交和远程的 origin 版本库的 master 分支之间的差异。git diff --cached —— 显示最近的本地提交与添加到本地索引的内容之间的任何差异。git stash —— 将索引的（已添加但未提交的）文件放在暂存区堆栈中。git stash list —— 显示暂存区堆栈中的变化。git stash pop —— 将最近的变化从暂存库中删除。无头骑士Git 里面有各种比喻。当我想到 HEAD 是哪里的时候，我就会想到火车线路。如果你最终处于 脱离的 HEAD detached HEAD 模式，就意味着你已经脱离了这个隐喻的轨道。HEAD 是指向当前签出分支中最近一次提交的指针。默认的“签出checkout”是指当你创建一个 Git 仓库并进入到 master 分支的时候。每次创建或修改到另一个分支时，你都会切换到该分支行。如果你在当前分支的某处进行 git checkout <commit>，HEAD 就会移动到该提交。如果没有提交历史记录将你的当前提交连接到已签出的提交，那么你将处于脱离的 HEAD 状态。如果你找不到 HEAD 的位置，你可以随时用 git reset --hard origin/master 来删除修改，回到已知状态。警告：这将删除你上次推送到 master 后的任何改动。你是上游还是下游？你的项目的本地副本被认为是你的本地版本库，它可能有也可能没有远程版本库 —— 远程版本库的副本是用于协作或保存的。也可能还有一个 上游 upstream 版本库，在那里，项目的第三个副本由不同的贡献者托管和维护。例如，假设我想为 Kubernetes 做贡献。我会首先将 kubernetes/kubernetes 项目 复刻 fork 到我的账户下 mbbroberg/kubernetes。然后我会将我的项目克隆到我的本地工作区。在这种情况下，我的本地克隆是我的本地仓库，mbbroberg/kubernetes 是我的远程仓库，kubernetes/kubernetes 是上游。合并的隐喻当你深入 Git 分支时，根系统的视觉效果就会和火车轨道的形象合二为一。分支通常被用作开发一个新功能的方式，最终你想把它 合并 merge 到主分支中。当这样做时，Git 会按顺序保留共同的提交历史，然后将你的分支的新提交追加到历史中。这个过程有一大堆的细节：是否 变基 rebase ，是否添加一个 合并提交 merge commit ，Brent Laster 在《如何在 Git 中重置、恢复和返回之前的状态》中会有更详细的探讨。我想现在就去 Git要掌握 Git 命令的世界，有大量的术语和需要探索的地方。我希望这篇关于日常使用术语的第一人称探索能帮助你适应这一切。如果你觉得自己被卡住了或者遇到了挫折，欢迎在 Twitter @mbbroberg 上联系我。回顾 提交 Commit —— 将当前索引的内容保存在一个新的提交中，并附上用户描述更改的日志信息。 分支 Branch —— 指向一个提交的指针。master —— 第一个分支的默认名称。HEAD —— 指向当前分支上最近一次提交的指针。 合并 Merge —— 合并两个或多个提交的历史。 工作空间 Workspace —— Git 仓库本地副本的通俗名称。 工作树 Working tree —— 工作区中的当前分支；任何时候你都可以在 git status 的输出中看到这个。 缓存 Cache —— 用于临时存储未提交的变更的空间。 索引 Index —— 变更提交前存储其变化的缓存。跟踪和未跟踪的文件 —— 没有被索引缓存的文件或尚未加入其中的文件。 暂存 Stash —— 另一个缓存，作为一个堆栈，在这里可以存储更改而不需要提交它们。origin —— 远程版本库的默认名称。 本地仓库 Local repository —— 也就是你在工作站上保存 Git 仓库副本的地方。 远程存储库 Remote repository —— Git 存储库的第二副本，你可以在这里推送变更以便协作或备份。 上游存储库 Upstream repository —— 你跟踪的远程存储库的通俗说法。 拉取请求 Pull request —— 这是 GitHub 的专用术语，用于让其他人知道你推送到仓库分支的变化。 合并请求 Merge request —— 这是 GitLab 的专用术语，用于让其他人知道你推送到仓库分支的变化。origin/master —— 远程版本库及其主要分支的默认名称。后记：双关语是 Git 最好的部分之一，愿你喜欢。via: https://opensource.com/article/19/2/git-terminology作者：Matthew Broberg 选题：lujun9972 译者：wxy 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
不管你是想要更舒服地从 Mac 搬到 Linux，还是不满意常规的 Linux 包管理器，都可以试试 Homebrew。Homebrew 项目最初是为了给 Mac 用户提供一个非官方的 Linux 式的包管理器。用户很快就爱上了它友好的界面以及帮助性的提示，而且，它已经被移植到 Linux 系统 —— 这看起来像是一个奇怪的命运转折。一开始，有两个分开的项目分别针对 macOS 和 Linux （Homebrew 与 Linuxbrew），但是现在是由 Homebrew 核心管理着这两个操作系统。由于我正 从 Mac 切换到 Linux，所以一直在研究我在 macOS 最常用的开源软件在 Linux 表现如何，最终，我很高兴地发现 Homebrew 对 Linux 的支持太赞了！为什么要在 Linux 使用 Homebrew 呢？长期使用 Linux 的用户对 Homebrew 的第一反应是：“为什么不直接使用……呢”，省略号代表他们喜欢的某个 Linux 包管理器。基于 Debian 的系统早就有了 apt，基于 Fedora 的系统则有 dnf 和 yum，并且像 Flatpak 跟 AppImage 这样的项目，在两种系统上都能流畅运行。我花了不少时间尝试这些技术，不得不说，它们都有其强大之处。那我为什么还要 坚持使用 Homebrew 呢？首先，我对它非常熟悉。在为我过去使用的专有软件寻找开源替代品的过程中，我已经学会了许多使用方法，而保持一些熟悉的东西，比如 Homebrew，可以让我专注于一次学习一件事情，而不是被不同系统间的差异搞垮。此外，我没有看到哪一个包管理器像 Homebrew 一样，对用户如此友好。正如默认的帮助命令一样，命令井然有序：$ brew -h Example usage: brew search [TEXT|/REGEX/] brew info [FORMULA...] brew install FORMULA... brew update brew upgrade [FORMULA...] brew uninstall FORMULA... brew list [FORMULA...] Troubleshooting: brew config brew doctor brew install --verbose --debug FORMULA Contributing: brew create [URL [--no-fetch]] brew edit [FORMULA...] Further help: brew commands brew help [COMMAND] man brew <https://docs.brew.sh> 过于简短的输出可能会被误解为它功能局限，但是你简单看看每一个子命令，都有很丰富的功能。虽然上面的列表只有短短 23 行，但对高级用户来说，光是子命令 install 就包含整整 79 行的帮助信息：$ brew --help | wc -l 23 $ brew install --help | wc -l 79 它可以选择忽略或者安装依赖关系，也可以选择用源代码编译以及用什么编译器来编译某个确切的上游 Git 提交，或者选择应用的官方 “灌装” 版。总而言之，Homebrew 即适合新手，也同样能满足老鸟。开始在 Linux 使用 Homebrew如果你想要试着使用 Homebrew，可以用这个单行脚本在 Mac 或者 Linux 上进行安装：$ /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)" 这条命令会立即开始安装 Homebrew。如果你比较谨慎，可以使用 curl 将该文件下载到本地，检查完毕之后再运行。$ curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh --output homebrew_installer.sh $ more homebrew_installer.sh # 审核该脚本，直到你觉得没问题了 $ bash homebrew_installer.sh 对 Linux 的安装步骤还包括如何配置点文件，对于 Debian 系统来说是 ~/.profile，对于 Fedora 系统是 ~/.bash_profile。$ test -d /home/linuxbrew/.linuxbrew && eval $(/home/linuxbrew/.linuxbrew/bin/brew shellenv) $ test -r ~/.bash_profile && echo "eval \$($(brew --prefix)/bin/brew shellenv)" >>~/.bash_profile $ echo "eval \$($(brew --prefix)/bin/brew shellenv)" >>~/.profile 为了确认已经安装好，Homebrew 团队提供一个空的 hello “秘方” 供测试：$ brew install hello ==> Downloading https://linuxbrew.bintray.com/bottles/hello-2.10.x86_64_linux.bottle.tar.gz ######################################################################## 100.0% ==> Pouring hello-2.10.x86_64_linux.bottle.tar.gz ? /home/linuxbrew/.linuxbrew/Cellar/hello/2.10: 52 files, 595.6KB 看起来安装毫无问题，让我来试试更多操作。命令行工具 BrewHomebrew 宣称自己是一款默认只 “安装你需要而 [Linux] 没有的东西”的应用程序。你可以用 brew 命令安装任何打包在 Homebrew 中的命令行软件。这些包的定义文件叫做 “ 秘方 formula ”，而且它们通过“ 瓶子 bottle ”来编译并分享。在 Homebrew 的世界里，还有许多 “啤酒方面” 的术语，但这个包管理器主要目的是让软件便于使用。都有些什么样的软件呢？对我这样的技术玩家（既然你已经在读这篇文章，估计你也是）来说最方便的东西。例如，便利的 tree 命令，可以展示目录结构，或者 pyenv，我用它来 在 Mac 管理不同版本 Python。你可以用 search 命令查看所有可以安装的“秘方”，在后面加上 wc 命令看看一共有多少：# -l 选项统计行数 $ brew search | wc -l 5087 迄今为止，一共有 5000 多个 “秘方”，这囊括了很多软件。需要注意的是：并非所有 “秘方” 都能在 Linux 运行。在 brew search --help 输出中有一节提到可以按软件运行的操作系统来筛选软件。它会在浏览器打开用于每个操作系统的软件仓库。我运行的是 Fedora，所以我会用它来试一试：$ brew search --fedora tree 浏览器打开了网址 https://apps.fedoraproject.org/packages/s/tree，向我展示了所有 Fedora 的可用选项。你也可以通过其它方法进行浏览。“秘方” 被集中整理到由操作系统划分的核心仓库当中（Mac 在 Homebrew Core，Linux 在 Linux Core）。同样也可以通过 Homebrew API 在网页显示。即使有这些选择，我还是通过其它用户的推荐找到很多新工具。我列出一些我最喜欢的工具，你可以在里面找点灵感：pyenv、rbenv 和 nodenv 用来管理（相应的） Python、Ruby 和 Node.js 版本imagemagick 用于脚本化编辑图片pandoc 用于脚本化转换文档格式（我通常将 .docx 文件转成 .md 或者 .html）hub 为 GitHub 用户提供 更好的 Git 体验tldr 展示了命令工具的使用范例想要深入了解 Homebrew，可以去 trldr 页面 看看，比起应用的 man 页面，它要友好得多。使用 search 命令确认你可以安装：$ brew search tldr ==> Formulae tldr ✔ 太好了！对勾说明你可以安装。那么继续吧：$ brew install tldr ==> Downloading https://linuxbrew.bintray.com/bottles/tldr-1.3.0_2.x86_64_linux.bottle.1.tar.gz ######################################################################## 100.0% ==> Pouring tldr-1.3.0_2.x86_64_linux.bottle.1.tar.gz ? /home/linuxbrew/.linuxbrew/Cellar/tldr/1.3.0_2: 6 files, 63.2KB Homebrew 提供了编译好的二进制文件，所以你不必在本地机器上从源码编译。这能节省很多时间，也不用听 CPU 风扇的噪声。我很欣赏 Homebrew 的另外一点是，你不完全理解每一个选项的含义也不会影响正常使用。若你想自己编译，可以在 brew install 命令后面加上 -s 或者 --build-from-source 标识，这样就能从源码编译 “秘方”（即便已经有一个 “瓶子” 存在）。同样，软件底层的复杂性也很有意思。使用 info 可以查看 tldr 软件的依赖管理，“秘方” 的源代码存放在磁盘上的何处，甚至还能查看公开分析。$ brew info tldr tldr: stable 1.3.0 (bottled), HEAD Simplified and community-driven man pages https://tldr.sh/ Conflicts with: tealdeer (because both install `tldr` binaries) /home/linuxbrew/.linuxbrew/Cellar/tldr/1.3.0_2 (6 files, 63.2KB) * Poured from bottle on 2020-06-08 at 15:56:15 From: https://github.com/Homebrew/linuxbrew-core/blob/master/Formula/tldr.rb ==> Dependencies Build: pkg-config ✔ Required: libzip ✔, curl ✔ ==> Options --HEAD Install HEAD version ==> Analytics install: 197 (30 days), 647 (90 days), 1,546 (365 days) install-on-request: 197 (30 days), 646 (90 days), 1,546 (365 days) build-error: 0 (30 days) 从 Mac 到 Linux 的一点不足在 macOS，Homebrew 的 cask（“酒桶”）子命令可以让用户使用命令行安装、管理整个应用软件。不幸的是，cask还不能在任何 Linux 发行版上使用。我在安装一个开源工具时发现了这点：$ brew cask install tusk Error: Installing casks is supported only on macOS 我在 论坛上 问了一下，很快得到其他用户的反馈。总结一下，方案如下：复刻 Homebrew 项目，构建这个特性，然后像别人展示其价值给该软件写一个 “秘方”，然后从源代码编译为该软件创建一个第三方仓库最后一个是我最感兴趣的。Homebrew 通过 创建并维护 “ 水龙头 tap ” （另一个受啤酒影响的术语）管理第三方仓库。随着你对系统越来越熟悉，并想加入生态系统， “水龙头” 是值得研究的。备份 Homebrew 的安装记录我最中意的 Homebrew 特性之一就是你可以像其它任何 用版本控制工具来备份点文件 一样备份你的安装记录。为了实现这个目的，Homebrew 提供 bundle（“捆扎”）子命令，它可以控制一个叫 dump（“倾倒”）的子命令生成一个 Brewfile。这个文件包含你目前所有安装的工具列表，可以重复使用。进入你想使用的目录然后运行命令，它会根据你所安装的软件生成 Brewfile：$ cd ~/Development/dotfiles # This is my dotfile folder $ brew bundle dump $ ls Brewfile Brewfile 当我换了一台机器，想要安装一样的软件时，进入含有 Brewfile 的文件夹，然后重新安装：$ ls Brewfile Brewfile $ brew bundle 它会在我的新机器上安装所有列出的 “秘方”。在 Mac 和 Linux 同时管理 BrewfileBrewfile 非常适合备份你目前的安装记录，但是如果某些在 Mac 上运行的软件无法运行在 Linux 呢？或者刚好相反？我发现不管是 Mac 还是 Linux，如果软件无法在当前操作系统运行，Homebrew 会优雅地忽略那一行。如果它遇到不兼容的请求（比如使用 brew 在 Linux 安装 “ 酒桶 cask ” 时），它会选择跳过，继续安装过程：$ brew bundle --file=Brewfile.example Skipping cask licecap (on Linux) Skipping cask macdown (on Linux) Installing fish Homebrew Bundle complete! 1 Brewfile dependency now installed. 为了保持配置文件的简洁，我在两个操作系统上使用同一份 Brewfile，因为它只安装与操作系统相关的版本，所以我一直没有遇到任何问题。使用 Homebrew 管理软件包Homebrew 已经成了我必备的命令行工具，由于我很熟悉它，所以在 Linux 上的体验也充满乐趣。Homebrew 让我的工具井然有序，并且时刻保持更新，我愈发欣赏它在实用性与功能上找到的平衡点。我更喜欢将软件包管理的细节保持在用户需要了解的最小程度，大多数人都会从中受益。如果你已经很熟悉 Linux 包管理器了，Homebrew 可能会让你觉得很基础，但稍微深入一点看，就会发现它的高级选项远远超过本文的内容。对 Linux 用户来说，他们有很多包管理器可以选择。如果你来自 MacOS，Homebrew 会让你宾至如归。via: https://opensource.com/article/20/6/homebrew-linux作者：Matthew Broberg 选题：lujun9972 译者：nophDog 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
Homebrew 软件包管理器可以让你轻松地在 Mac 上安装和更新应用程序和实用程序。在我追求“万物自动化”的过程中，我一直坚持走在用代码来管理我的 Mac 笔记本电脑的路上。与其用鼠标或触控板手动管理我的应用程序和实用程序，我更喜欢使用软件包管理软件来安装、更新和删除不需要的软件。这对 Mac 用户来说是个挑战。Mac 的操作系统 macOS 始终落后于 Linux 的一个地方就是在包管理方面。Mac 用户没有默认的软件包管理器，而 Linux 用户则有很多选择 —— 从熟悉的 yum 和 apt 到现代的 Flatpak。但 Mac 呢？这就是 Homebrew 的作用。Homebrew（自酿）填补了 MacOS 事实上的软件包管理器的空白（它也是 Linux 上的又一个可选的包管理器）。它为任何熟悉命令行的人提供了令人难以置信的流畅而直接的体验，如果你是新手，它是学习命令行的好方法。（LCTT 译注：Homebrew 系统中采用了大量针对自酿啤酒相关的比喻，大家在使用过程中会发现这些有趣的形容。）如果你在 Mac 上还没有 Homebrew，你可以这样来安装：$ /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)" 该命令将执行 Homebrew 团队提供的安装程序脚本。如果你喜欢谨慎一点，可以 curl 下来这个文件，审核后再手动运行。$ curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh --output homebrew_installer.sh $ more homebrew_installer.sh # 审核该脚本，直到你觉得没问题了 $ bash homebrew_installer.sh 使用“酿造”来管理你的命令行实用程序Homebrew 号称它“可以安装苹果（或你的 Linux 系统）默认没有安装的必需之物”。安装是通过 brew（酿造）命令进行的，它使我们能够访问成千上万的命令行实用程序，但不是更复杂的应用程序。对于我们这些搞技术的人来说，符合“必需之物”类别的实用工具包括显示目录结构的方便的 tree 命令和我用来 管理多个 Python 版本 的 pyenv。你可以用 search 子命令看到 Homebrew 中所有的“ 秘方 formula ”，我用 wc 命令显示有多少个“秘方”。# -l 统计行数 $ brew search | wc -l 5013 有 5000 多个“秘方”，这是一个不可思议的软件数量。所以，在搜索那个庞大的清单之前，最好先对自己想要的东西有个概念。值得庆幸的是，浏览起来很方便。“秘方”被编入并集中存储到核心库中，核心库按操作系统划分（Mac 在 Homebrew Core，Linux 在 Linux Core）。它们也可以通过 Homebrew API 和网站列出。口碑是另一个寻找实用工具的好方法。考虑到这一点，如果你正在寻找灵感，这里有一些我的最爱：pyenv、rbenv 和 nodenv 分别用于管理 Python、Ruby 和 Node.js 的版本imagemagick 用于可脚本化的图像编辑pandoc 用于可脚本化的文件转换（我经常从 .docx 切换到 .md 或 .html）hub 为 GitHub 用户提供了更好的 Git 体验。tldr 提供了解如何使用命令行工具的例子举个例子，看看 tldr 页面，这是一个用户友好的替代方式，可以滚动浏览应用程序的手册页。你可以通过再次运行 search 来确认它是否可用：$ brew search tldr ==> Formulae tldr ✔ 成功了！这个对勾让你知道它是可用的。现在你可以安装它了：$ brew install tldr ==> Downloading https://homebrew.bintray.com/bottles/tldr-1.3.0_2.catalina.bottle.tar.gz Already downloaded: /Users/mbbroberg/Library/Caches/Homebrew/downloads/901bc14594a9283e9ab20aec942dc5a9a2befb7e96e1b0fcccb4e3257918813c--tldr-1.3.0_2.catalina.bottle.tar.gz ==> Installing tldr ==> Pouring tldr-1.3.0_2.catalina.bottle.tar.gz ? /usr/local/Cellar/tldr/1.3.0_2: 6 files, 35.5KB 值得庆幸的是，Homebrew 预先构建了二进制文件，所以你不必在本地机器上从源代码构建。这样就节省了很多时间，并免除了 CPU 风扇的噪音。我对 Homebrew 赞赏的另一件事是，你可以在不完全了解其含义的情况下欣赏此功能。但如果你喜欢，看看复杂的东西也是很有趣的。对 tldr 运行 info 子命令，你可以看到所有的依赖管理、源代码，甚至公共分析。$ brew info tldr tldr: stable 1.3.0 (bottled), HEAD Simplified and community-driven man pages https://tldr.sh/ Conflicts with: tealdeer (because both install `tldr` binaries) /usr/local/Cellar/tldr/1.3.0_2 (6 files, 35.5KB) * Poured from bottle on 2020-05-20 at 15:12:12 From: https://github.com/Homebrew/homebrew-core/blob/master/Formula/tldr.rb ==> Dependencies Build: pkg-config ✔ Required: libzip ✔ ==> Options --HEAD Install HEAD version ==> Analytics install: 2,811 (30 days), 7,875 (90 days), 27,105 (365 days) install-on-request: 2,806 (30 days), 7,860 (90 days), 27,080 (365 days) build-error: 0 (30 days) 最后，和其他优秀的软件包管理器一样，Homebrew 的 brew uninstall 子命令可用于快速清理和删除未使用的实用程序。用“酒桶”管理你的应用程序命令行实用程序是一匹孤狼，但完整的应用程序呢？Homebrew 保持了其标准命令的简单性，只通过其默认的 brew 命令行界面安装单文件应用。而应用程序不符合这种结构。它们的目录层次比较复杂，比单一的二进制要复杂得多。幸运的是，Mac 上的 Homebrew 包含了一个名为 cask（酒桶）的子命令，用于处理更复杂的多目录结构。特别好的是，cask 使用了与标准 brew 命令类似的命令结构，所以你可以使用类似的 search、install 和 info 子命令：brew search --cask | wc -l 4772 哇，有近 5000 个应用程序，在 Homebrew 的网站上浏览更方便。我将用我新喜欢的一款应用来引导你完成 cask。Meld（我在 Opensource.com 上读到的）。这是一个功能丰富的编辑器，可以帮助管理合并冲突。在它的网站上有下载的链接，我可以运行安装程序，并将其拖放到我的应用程序文件夹中。但我不想再这样做了，我用的是 Homebrew。首先，我可以通过稍微不同的语法确认它可以使用：$ brew search --casks meld ==> Casks meld 然后我使用 cask 子命令来安装它：$ brew cask install meld ==> Downloading https://github.com/yousseb/meld/releases/download/osx-19/meldmerge.dmg ==> Downloading from https://github-production-release-asset-2e65be.s3.amazonaws.com/28624006/66cb25 ######################################################################## 100.0% ==> Verifying SHA-256 checksum for Cask 'meld'. ==> Installing Cask meld ==> Moving App 'Meld.app' to '/Applications/Meld.app'. ==> Linking Binary 'meld.wrapper.sh' to '/usr/local/bin/meld'. ? meld was successfully installed! Homebrew 不仅安装了应用程序，而且还在我当前的路径 /usr/local/bin/ 下提供了它。现在，我可以从命令行运行 meld 或从应用程序文件夹中启动应用程序。更新一切的“酿造升级”我一直使用软件包管理器的主要原因是，我可以不断升级我的软件，以避免已知的安全漏洞，并确保我总是有最新的功能。如果我手工安装所有的东西，我必须关注每一个工具和应用程序，以了解它是否有自动更新程序，如果没有，就得自己拉回最新的版本。升级功能是优秀的软件包管理的闪光点。由于我没有什么特殊的版本要求，所以我只需要运行一个命令就可以顺利更新一切：$ brew upgrade ==> Upgrading 6 outdated packages: helm 3.2.1 -> 3.2.2 python@3.8 3.8.2_4 -> 3.8.3 ipython 7.14.0 -> 7.15.0 go 1.14.2_1 -> 1.14.3 libzip 1.6.1 -> 1.6.1_1 sqlite 3.31.1 -> 3.32.1 如果你有更复杂的需求，或者想在安装升级前关注一下升级情况，有很多功能标志可供选择。例如，-n 提供了一个 “模拟运行”，列出了可用的升级，而不会进行安装。你也可以 “钉” 住应用程序版本来防止它升级。备份你的安装当该工具允许你像其它点文件的版本控制方案一样备份你的安装环境时，命令行实用程序和应用程序的管理就跳到了一个全新的水平。Homebrew 就有这样的功能，可以在 dump 子命令下使用。它会生成一个 Brewfile，这是一个可重复使用的当前所有安装的工具的列表。要从你的安装的环境中生成一个，进入你的合适的文件夹并运行：$ cd ~/Development/dotfiles # 这是我的点文件的文件夹 $ brew bundle dump 当我换了机器，想用 Homebrew 安装相同的应用程序时，我就会进入装有 Brewfile 的文件夹并运行。$ brew bundle 它将在我的新机器上安装所有列出的“秘方”和“酒桶”。用 Homebrew 进行软件包管理Homebrew 是我常用的命令行工具和应用程序的管理器。它可以让我保持有条理和及时更新，它的设计在易用性和功能深度之间取得了美丽的平衡。Homebrew 将软件包管理的细节最小化到只需要你知道的程度，大多数用户都会从中受益。如果你对 Linux 软件包管理器已经驾轻就熟，你可能会认为 Homebrew 太简单了，但不要误以为 Homebrew 的易用性是功能的缺乏。稍微深入一点看，就会发现很多高级选项，远远超出了我在这里向你展示的范围。将 -h 添加到任何 brew 子命令中，会显示可用来升级、删除、故障排除，甚至使用模板贡献新 “秘方” 的丰富功能。总的来说，Homebrew 可以让一个重度命令行的 Mac 用户变得很开心。此外，它是开源的，所以如果你愿意，你可以贡献代码。尝试一下它，让我知道你的想法，在下面留下评论。via: https://opensource.com/article/20/6/homebrew-mac作者：Matthew Broberg 选题：lujun9972 译者：wxy 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
如果你在 macOS 上运行的项目需要没有安装的 Python 版本，请试试 pyenv。即使对于有经验的开发人员，管理本地 Python 开发环境仍然是一个挑战。尽管有详细的软件包管理策略，但仍需要采取另外的步骤来确保你在需要时运行所需的 Python 版本。为什么 Python 版本重要？起初这是一个奇怪的概念，但是编程语言会像其他任何软件一样发生变化。它们有错误、修复和更新，就像你喜欢的 API 和任何其他软件一样。同样，不同的发行版由称为语义化版本的三位数标识。??? pic.twitter.com/yt1Z2439W8— Denny Perez (@dennyperez18) May 28, 2019多年来，Python 2 是该语言的常用主要版本。在 2020 年 1 月，Python 2 到达最后寿命，此后，Python 的核心维护者将仅支持 Python 3。Python 3 稳步发展，并定期发布新更新。对我来说定期获取这些更新很重要。最近，我试图在 macOS 上运行一个依赖于 Python 3.5.9 的项目，而我的系统上并没有安装这个版本。我认为 Python 包管理器 pip 可以安装它，但事实并非如此：$ pip install python3.5.9 Collecting python3.5.9 ERROR: Could not find a version that satisfies the requirement python3.5.9 (from versions: none) ERROR: No matching distribution found for python3.5.9或者，我也可以从官方 Python 网站下载该版本，但我如何在我的 Mac 上与现有的 Python 版本一起运行？每次运行时指定 Python 解释器版本（例如 python3.7 或 python3.5）似乎很容易出错。一定会有更好的方法。（说明：我知道这对经验丰富的 Python 开发人员没有意义，但对当时的我来说是有意义的。我很乐意谈一谈为什么我仍然认为它应该这样做。）安装和设置 pyenv值得庆幸的是，pyenv 可以绕开这一系列复杂的问题。首先，我需要安装 pyenv。我可以从源码克隆并编译它，但是我更喜欢通过 Homebrew 包管理器来管理软件包：$ brew install pyenv为了通过 pyenv 使用 Python 版本，必须了解 shell 的 PATH 变量。PATH 决定了 shell 通过命令的名称来搜索文件的位置。你必须确保 shell 程序能够找到通过 pyenv 运行的 Python 版本，而不是默认安装的版本（通常称为系统版本）。如果不更改路径，那么结果如下：$ which python /usr/bin/python这是 Python 的系统版本。要正确设置 pyenv，可以在 Bash 或 zsh 中运行以下命令：$ PATH=$(pyenv root)/shims:$PATH现在，如果你检查 Python 的版本，你会看到它是 pyenv 管理的版本：$ which python /Users/my_username/.pyenv/shims/python该导出语句（PATH=）仅会对该 shell 实例进行更改，为了使更改永久生效，你需要将它添加到点文件当中。由于 zsh 是 macOS 的默认 shell，因此我将重点介绍它。将相同的语法添加到 ~/.zshrc 文件中：$ echo 'PATH=$(pyenv root)/shims:$PATH' >> ~/.zshrc现在，每次我们在 zsh 中运行命令时，它将使用 pyenv 版本的 Python。请注意，我在 echo 中使用了单引号，因此它不会评估和扩展命令。.zshrc 文件仅管理 zsh 实例，因此请确保检查你的 shell 程序并编辑关联的点文件。如果需要再次检查默认 shell 程序，可以运行 echo $SHELL。如果是 zsh，请使用上面的命令。如果你使用 Bash，请将 ~/.zshrc 更改为 ~/.bashrc。如果你想了解更多信息，可以在 pyenv 的 README 中深入研究路径设置。使用 pyenv 管理 Python 版本现在 pyenv 已经可用，我们可以看到它只有系统 Python 可用：$ pyenv versions system如上所述，你绝对不想使用此版本（阅读更多有关信息）。现在 pyenv 已正确设置，我希望它能有我经常使用的几个不同版本的 Python。有一种方法可以通过运行 pyenv install --list 来查看 pyenv 可以访问的所有仓库中的所有 Python 版本。这是一个很长的列表，将来回顾的时候可能会有所帮助。目前，我决定在 Python 下载页面找到的每个最新的“点版本”（3.5.x 或 3.6.x，其中 x 是最新的）。因此，我将安装 3.5.9 和 3.8.0：$ pyenv install 3.5.9 $ pyenv install 3.8.0这将需要一段时间，因此休息一会（或阅读上面的链接之一）。有趣的是，输出中显示了该版本的 Python 的下载和构建。例如，输出显示文件直接来自 Python.org。安装完成后，你可以设置默认值。我喜欢最新的，因此将全局默认 Python 版本设置为最新版本：$ pyenv global 3.8.0该版本立即在我的 shell 中设置完成。确认一下：$ python -V Python 3.8.0我要运行的项目仅适于 Python 3.5，因此我将在本地设置该版本并确认：$ pyenv local 3.5.9 $ python -V Python 3.5.9因为我在 pyenv 中使用了 local 选项，所以它向当前目录添加了一个文件来跟踪该信息。$ cat .python-version 3.5.9现在，我终于可以为想要的项目设置虚拟环境，并确保运行正确版本的 Python。$ python -m venv venv $ source ./venv/bin/activate (venv) $ which python /Users/mbbroberg/Develop/my_project/venv/bin/python要了解更多信息，请查看有关在 Mac 上管理虚拟环境的教程。总结默认情况下，运行多个 Python 版本可能是一个挑战。我发现 pyenv 可以确保在我需要时可以有我需要的 Python 版本。你还有其他初学者或中级 Python 问题吗？ 请发表评论，我们将在以后的文章中考虑介绍它们。via: https://opensource.com/article/20/4/pyenv作者：Matthew Broberg 选题：lujun9972 译者：geekpi 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
我们邀请 Opensource.com 的 DevOps 团队，希望他们能够谈一谈作为 DevOps 内向者的休验，同时给 DevOps 外向者一些建议。下面是他们的回答。我们邀请我们的 DevOps 团队 谈一谈他们作为一个内向者的体验，并给外向者们一些建议。但是在我们开始了解他们的回答之前，让我们先来定义一下这些词汇。“内向者”是什么意思？内向者通常指的是一部分人群，当他们和别人相处的时候，会使他们的能量耗尽，而不是激发他们更多的能量。当我们思考我们是如何恢复能量时，这是一个非常有用的词汇：内向者通常需要更多的独处时间来恢复能量，特别是和一群人在一起很长时间后。关于内向者的一个非常大的误解就是他们一定是“害羞的”，但是科学表明，那不过是另一种不同的性格特征。内向性与外向性是通过 Myers Briggs 类型指标 而为人所知的，现在也常常被称作一个 光谱 的两端。虽然这个世界看起来好像外向者比内向者要多，但是心理学者则倾向于认为大部分人在光谱上的位置是落在 中间性格或偏内向性格的。现在，我们来看看问答。DevOps 技术主管可以通过哪些方式来让内向者感觉他们是团队的一部分并且愿意分享他们的想法？“每个人都会不大一样，所以观察敏锐就很重要了。从 GitLab 过来的一个人告诉我，他们的哲学就是如果他们没有提供任何意见，那么他们就是被排除在外的。如果有人在一个会议上没有提供任何的意见，那就想办法让他们加入进来。当我知道一个内向者对我们将要讨论的会议论题感兴趣的时候，我会提前请他写一些书面文本。有非常多的会议其实是可以避免的，只要通过把讨论放到 Slack 或者 GitLab 上就行了，内向者会更愿意参与进来。在站立会议中，每个人都会交代最新的进展，在这个环境下，内向者表现得很好。有时候我们在其实会议上会重复做一些事情，仅仅是为了保证每个人都有时间发言。我同时也会鼓励内向者在工作小组或者社区小组面前发言，以此来锻炼他们的这些技能。”—— 丹·巴克“我觉得别人对我做的最好的事情，就是他们保证了当重大问题来临的时候，我拥有必要的技能去回答它。彼时，我作为一名非常年轻的入伍空军的一员，我需要给我们部队的高级领导做状态简报的汇报。我必须在任何时候都有一些可用的数据点，以及在实现我们确立的目标的过程中，产生延误以及偏差的背后的原因。那样的经历推动着我从一个‘幕后人员’逐渐变得更加愿意和别人分享自己的观点和想法。”—— 克里斯·肖特“通过文化去领导。为你的同僚一起设计和尝试仪式。你可以为给你的小组或团队设计一个小的每周仪式，甚至给你的部门或组织设计一个年度的大仪式。它的意义在于去尝试一些事物，并观察你在其中的领导角色。去找到你们文化当中的代沟以及对立。回顾团队的信仰和行为。你能从哪里观察到对立？你们的文化中缺失了什么？从一个小陈述开始‘我从 X 和 Y 之间看到了对立’，或者‘我的团队缺少了 Z’。接着，将代沟与对立转换为问题：写下三个‘我们如何能……(How might we’s, HMWs)’。”—— 凯瑟琳·路易斯“内向者不是一个不同的群体，他们要么是在分享他们的想法之前想得太多或等得太久的一些人，要么就是一些根本不知道发生了什么的人。我就是第一种，我想太多了，有时候还担心我的意见会被其他人嘲笑，或者没有什么意思，或者想偏了。形成那样的思维方式很难，但它同时也在吞噬着我学习更好事物的机会。有一次，我们团队在讨论一个实现问题。我当时的老大一次又一次地问我，为什么我没有作为团队中更具经验的人参与进来，然后我就（集齐了全宇宙的力量之后）开口说我想说的大家都已经说过了。他说，有时候我可以重复说一次，事情纷繁，如果你能够重复一遍你的想法，即使它已经被讨论过了，也会大有裨益。好吧，虽然它不是一种特别信服的方式，但是我知道了至少有人想听听我怎么说，它给了我一点信心。“现在，我所使用的让团队中的人发言的方法是我经常向内向的人求助，即使我知道解决方法，并且在团队会议和讨论中感谢他们来建立他们的自信心，通过给他们时间让他们一点一点的从他们寡言的本性中走出来，从而跟团队分享很多的知识。他们在外面的世界中可能仍然会有一点点孤立，但是在团队里面，有些会成为我们可以信赖的人。”—— 阿布希什克·塔姆拉卡尔“我给参加会议的内向者的建议是，找一个同样要参加会议的朋友或者同事，这样到时你就会有人可以跟你一起舒服地交谈，在会议开始之前，提前跟其他的与会者（朋友、行业联系人、前同事等等）约着见个面或者吃顿饭，要注意你的疲劳程度，并且照顾好自己：如果你需要重新恢复能量，就跳过那些社交或者夜晚的活动，在事后回顾中记录一下自己的感受。”—— 伊丽莎白·约瑟夫和一个内向者倾向的同事一起工作时，有什么提高生产效率的小建议？“在保证质量时，生产效率会越来越具备挑战性。在大多数时候，工作中的一个小憩或者轻松随意的交谈，可能正是我们的创造性活动中需要的一个火花。再说一次，我发现当你的团队中有内向者时， Slack 和 Github 会是一个非常有用的用于交换想法以及和其他人互动的媒介。我同时也发现，结对编程对于大部分的内向者也非常有用，虽然一对一的交流对于他们来说，并不像交税那么频繁，但是生产质量和效率的提升却是重大的。但是，当一个内向者在独自工作的时间，团队中的所有人都不应该去打断他们。最好是发个邮件，或者使用没有那么强的侵入性的媒介。”—— 丹·巴克“给他们趁手的工具，让他们工作并归档他们的工作。让他们能够在他们的工作上做到最好。要足够经常地去检查一下，保证他们没有走偏路，但是要记住，相比外向者而言，这样做是更大的一种让人分心的困扰。”—— 克里斯·肖特“当我低着头的时候，不要打断我。真的，别打断我！当我沉浸在某件事物中时，这样做会造成我至少需要花费两个小时，才能让我的大脑重新回到之前的状态。感觉很痛苦。真的。你可以发个邮件让我去有白板的地方。然后从客户的角度而不是你的角度——通过画图的方式——分享下有什么问题。要知道，可能同时会有十几个客户问题缠绕在我的脑海中，如果你的问题听起来就是‘这样子做会让我在我的领导面前显得很好’的那一类问题，那么相比我脑袋中已经有的真正的客户问题而言，它不会得到更多的关注的。画个图，给我点时间思考。当我准备分享我的看法的时候，保证有多支马克笔可以使用。准备好接受你对问题的假设有可能完全是错误的。”—— 凯瑟琳·路易斯“感谢和鼓励就是解决的方法，感谢可能不是一份工作评估，但是感谢能让人舒服地感受到自己并不仅仅是一个活着的独立实体，因而每个人都能够感觉到自己是被倾听的，而不是被嘲笑或者低估的。”—— 阿布希什克·塔姆拉卡尔结语在与内向的 DevOps 爱好者的这次交谈中，我们最大的启迪就是平等：其他人需要被怎样对待，就怎样对待他们，同时你想被怎样对待，就去要求别人怎样对待你。无论你是内向还是外向，我们都需要承认我们并非全以相同的一种方式体验这个世界。我们的同事应当被给予足够的空间以完成他们的工作，通过讨论他们的需求作为了解如何支持他们的开始。我们的差异正是我们的社区如此特别的原因，它让我们的工作对更多的人更加的有用。与别人沟通最有效的方式，就是对于你们两者而言都可行的方式。via: https://opensource.com/article/19/7/devops-introverted-people作者：Matthew Broberg 选题：lujun9972 译者：XLCYun 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
感谢这么多的开源开发人员，日常使用 Linux 比以往任何时候都容易得多。自 2004 年开始从事 IT 工作以来，我一直是 Mac 的忠实粉丝。但是几个月前，由于种种原因，我决定将 Linux 用作日常使用的系统。这不是我第一次尝试完全采用 Linux，但是我发现它比以往更加容易。下面是促使我转换的原因。我在个人电脑上的首次 Linux 体验我记得，我抬头看着投影机，而它和我面面相觑。我们俩都不明白为什么它不显示。VGA 线完全接好了，针脚也没有弯折。我按了我所有想到的可能的按键组合，以向我的笔记本电脑发出信号，想让它克服“舞台恐惧症”。我在大学里运行 Linux 只是作为实验。而我在 IT 部门的经理是多种口味的倡导者，随着我对桌面支持和编写脚本的信心增强，我想了解更多 Linux 的信息。对我来说，IT 比我的计算机科学学位课程有趣得多，课程的感觉是如此抽象和理论化：“二叉树有啥用？”，我如是想 —— 而我们的系统管理员团队的工作却是如此的真真切切。这个故事的结尾是，我登录到 Windows 工作站完成了我的课堂演讲，这标志着我将 Linux 作为我的日常操作系统的第一次尝试的终结。我很欣赏 Linux 的灵活性，但是它缺乏兼容性。我偶尔会写个脚本，脚本通过 SSH 连接到一个机器中以运行另一个脚本，但是我对 Linux 的日常使用仅止于此。对 Linux 兼容性的全新印象几个月前，当我决定再试一次 Linux 时，我曾觉得我遇到更多的兼容性噩梦，但我错了。安装过程完成后，我立即插入了 USB-C 集线器以了解兼容性到底如何。一切立即工作。连接 HDMI 的超宽显示器作为镜像显示器弹出到我的笔记本电脑屏幕上，我轻松地将其调整为第二台显示器。USB 连接的网络摄像头对我的在家工作方式至关重要，它可以毫无问题地显示视频。甚至自从我使用 Mac 以来就一直插在集线器的 Mac 充电器可以为我的非常不 Mac 的硬件充电。我的正面体验可能与 USB-C 的一些更新有关，它在 2018 年得到一些所需的关注，因此才能与其他操作系统的体验相媲美。正如 Phoronix 解释的那样：“USB Type-C 接口为非 USB 信号提供了‘替代模式’扩展，在规范中该替代模式的最大使用场景是支持 DisplayPort。除此之外，另一个替代模式是支持 Thunderbolt 3。DisplayPort 替代模式支持 4K 甚至 8Kx4K 的视频输出，包括多声道音频。“虽然 USB-C 替代模式和 DisplayPort 已经存在了一段时间，并且在 Windows 上很常见，但是主线 Linux 内核不支持此功能。所幸的是，多亏英特尔，这种情况正在改变。”而在端口之外，快速浏览一下 笔记本电脑 Linux 的硬件选择，列出了比我 2000 年代初期所经历的更加完整的选择集。与我第一次尝试采用 Linux 相比，这已经天差地别，这是我张开双臂欢迎的。突破 Apple 的樊篱使用 Linux 给我的日常工作流程增加了一些新的麻烦，而我喜欢这种麻烦。我的 Mac 工作流程是无缝的：早上打开 iPad，写下关于我今天想要做什么的想法，然后开始在 Safari 中阅读一些文章；移到我的 iPhone 上可以继续阅读；然后登录我的 MacBook，这些地方我进行了多年的微调，已经弄清楚了所有这些部分之间的连接方式。键盘快捷键已内置在我的大脑中；用户体验一如既往。简直不要太舒服了。这种舒适需要付出代价。我基本上忘记了我的环境如何运作的，也无法解答我想解答的问题。我是否自定义了一些 PLIST 文件以获得快捷方式，是不是记得将其签入我的 dotfiles 当中？当 Firefox 的功能更好时，我为何还如此依赖 Safari 和 Chrome？为什么我不使用基于 Android 的手机代替我的 i-系列产品呢？关于这一点，我经常考虑改用基于 Android 的手机，但是我会失去在所有这些设备之间的连接性以及为这种生态系统设计的一些便利。例如，我将无法在 iPhone 上为 Apple TV 输入搜索内容，也无法与其他用 Apple 的朋友用 AirDrop 共享密码。这些功能是同类设备环境的巨大好处，并且是一项了不起的工程。也就是说，这些便利是被生态系统所困的代价。我喜欢了解设备的工作方式。我希望能够解释使我的系统变得有趣或容易使用的环境配置，但我也想看看增加一些麻烦对我的观点有什么影响。用 Marcel Proust 的话来说，“真正的发现之旅不在于寻找新的土地，而在于用新的眼光来看待。”技术的使用是如此的方便，以至于我不再对它的工作原理感到好奇，而 Linux 使我有机会再次有了新的眼光。受你的启发以上所有内容足以成为探索 Linux 的理由，但我也受到了你的启发。尽管所有操作系统都受到开源社区的欢迎，但 Opensource.com 的作者和读者对 Linux 的喜悦是充满感染力的。它激发了我重新潜入的乐趣，我享受这段旅途的乐趣。via: https://opensource.com/article/19/10/why-switch-mac-linux作者：Matthew Broberg 选题：lujun9972 译者：wxy 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
通过在 GitLab 或 GitHub 上分享你的点文件，可以在整个系统上备份或同步你的自定义配置。通过隐藏文件集（称为 点文件 dotfile ）来定制操作系统是个非常棒的想法。在这篇 Shell 点文件可以为你做点什么中，H. Waldo Grunenwald 详细介绍了为什么以及如何设置点文件的细节。现在让我们深入探讨分享它们的原因和方式。什么是点文件？“ 点文件 dotfile ”是指我们计算机中四处漂泊的配置文件。这些文件通常在文件名的开头以 . 开头，例如 .gitconfig，并且操作系统通常在默认情况下将其隐藏。例如，当我在 MacOS 上使用 ls -a 时，它才会显示所有可爱的点文件，否则就不会显示这些点文件。dotfiles on master ➜ ls README.md Rakefile bin misc profiles zsh-custom dotfiles on master ➜ ls -a . .gitignore .oh-my-zsh README.md zsh-custom .. .gitmodules .tmux Rakefile .gemrc .global_ignore .vimrc bin .git .gvimrc .zlogin misc .gitconfig .maid .zshrc profiles如果看一下用于 Git 配置的 .gitconfig，我能看到大量的自定义配置。我设置了帐户信息、终端颜色首选项和大量别名，这些别名可以使我的命令行界面看起来就像我的一样。这是 [alias] 块的摘录：87 # Show the diff between the latest commit and the current state 88 d = !"git diff-index --quiet HEAD -- || clear; git --no-pager diff --patch-with-stat" 89 90 # `git di $number` shows the diff between the state `$number` revisions ago and the current state 91 di = !"d() { git diff --patch-with-stat HEAD~$1; }; git diff-index --quiet HEAD -- || clear; d" 92 93 # Pull in remote changes for the current repository and all its submodules 94 p = !"git pull; git submodule foreach git pull origin master" 95 96 # Checkout a pull request from origin (of a github repository) 97 pr = !"pr() { git fetch origin pull/$1/head:pr-$1; git checkout pr-$1; }; pr"由于我的 .gitconfig 有 200 多行的自定义设置，我无意于在我使用的每一台新计算机或系统上重写它，其他人肯定也不想这样。这是分享点文件变得越来越流行的原因之一，尤其是随着社交编码网站 GitHub 的兴起。正式提倡分享点文件的文章是 Zach Holman 在 2008 年发表的《点文件意味着被复刻》。其前提到今天依然如此：我想与我自己、与点文件新手，以及那些分享了他们的自定义配置从而教会了我很多知识的人分享它们。分享点文件我们中的许多人拥有多个系统，或者知道硬盘变化无常，因此我们希望备份我们精心策划的自定义设置。那么我们如何在环境之间同步这些精彩的文件？我最喜欢的答案是分布式版本控制，最好是可以为我处理繁重任务的服务。我经常使用 GitHub，随着我对 GitLab 的使用经验越来越丰富，我肯定会一如既往地继续喜欢它。任何一个这样的服务都是共享你的信息的理想场所。要自己设置的话可以这样做：登录到你首选的基于 Git 的服务。创建一个名为 dotfiles 的存储库。（将其设置为公开！分享即关爱。）将其克隆到你的本地环境。（你可能需要设置 Git 配置命令来克隆存储库。GitHub 和 GitLab 都会提示你需要运行的命令。）将你的点文件复制到该文件夹中。将它们符号链接回到其目标文件夹（最常见的是 $HOME）。将它们推送到远程存储库。上面的步骤 4 是这项工作的关键，可能有些棘手。无论是使用脚本还是手动执行，工作流程都是从 dotfiles 文件夹符号链接到点文件的目标位置，以便对点文件的任何更新都可以轻松地推送到远程存储库。要对我的 .gitconfig 文件执行此操作，我要输入：$ cd dotfiles/ $ ln -nfs .gitconfig $HOME/.gitconfig添加到符号链接命令的标志还具有其他一些用处：-s 创建符号链接而不是硬链接。-f 在发生错误时继续做其他符号链接（此处不需要，但在循环中很有用）-n 避免符号链接到一个符号链接文件（等同于其他版本的 ln 的 -h 标志）如果要更深入地研究可用参数，可以查看 IEEE 和开放小组的 ln 规范以及 MacOS 10.14.3 上的版本。自从其他人的点文件中拉取出这些标志以来，我才发现了这些标志。你还可以使用一些其他代码来简化更新，例如我从 Brad Parbs 复刻的 Rakefile。另外，你也可以像 Jeff Geerling 在其点文件中那样，使它保持极其简单的状态。他使用此 Ansible 剧本对文件进行符号链接。这样使所有内容保持同步很容易：你可以从点文件的文件夹中进行 cron 作业或偶尔进行 git push。简单旁注：什么不能分享在继续之前，值得注意的是你不应该添加到共享的点文件存储库中的内容 —— 即使它以点开头。任何有安全风险的东西，例如 .ssh/ 文件夹中的文件，都不是使用此方法分享的好选择。确保在在线发布配置文件之前仔细检查配置文件，并再三检查文件中没有 API 令牌。我应该从哪里开始？如果你不熟悉 Git，那么我有关 Git 术语的文章和常用命令备忘清单将会帮助你继续前进。还有其他超棒的资源可帮助你开始使用点文件。多年前，我就发现了 dotfiles.github.io，并继续使用它来更广泛地了解人们在做什么。在其他人的点文件中隐藏了许多秘传知识。花时间浏览一些，大胆地将它们添加到自己的内容中。我希望这是让你在计算机上拥有一致的点文件的快乐开端。你最喜欢的点文件技巧是什么？添加评论或在 Twitter 上找我 @mbbroberg。via: https://opensource.com/article/19/3/move-your-dotfiles-version-control作者：Matthew Broberg 选题：lujun9972 译者：wxy 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
本周的《代码英雄》播客深入研究了最广泛使用的、已经成为事实标准的脚本语言，它来自于自由软件基金会及其作者的早期灵感。对于任何从事于系统管理员方面的人来说，Shell 脚本编程是一门必不可少的技能，而如今人们编写脚本的主要 shell 是 Bash。Bash 是几乎所有的 Linux 发行版和现代 MacOS 版本的默认配置，也很快就会成为 Windows 终端的原生部分。你可以说 Bash 无处不在。那么它是如何做到这一点的呢？本周的《代码英雄》播客将通过询问编写那些代码的人来深入研究这个问题。肇始于 Unix像所有编程方面的东西一样，我们必须追溯到 Unix。shell 的简短历史是这样的：1971 年，Ken Thompson 发布了第一个 Unix shell：Thompson shell。但是，脚本用户所能做的存在严重限制，这意味着严重制约了自动化以及整个 IT 运营领域。这个奇妙的研究概述了早期尝试脚本的挑战：类似于它在 Multics 中的前身，这个 shell（/bin/sh）是一个在内核外执行的独立用户程序。诸如通配（参数扩展的模式匹配，例如 *.txt）之类的概念是在一个名为 glob 的单独的实用程序中实现的，就像用于计算条件表达式的 if 命令一样。这种分离使 shell 变得更小，才不到 900 行的 C 源代码。shell 引入了紧凑的重定向（<、> 和 >>）和管道（| 或 ^）语法，它们已经存在于现代 shell 中。你还可以找到对调用顺序命令（;）和异步命令（＆）的支持。Thompson shell 缺少的是编写脚本的能力。它的唯一目的是作为一个交互式 shell（命令解释器）来调用命令和查看结果。随着对终端使用的增长，对自动化的兴趣随之增长。Bourne shell 前进一步在 Thompson 发布 shell 六年后，1977 年，Stephen Bourne 发布了 Bourne shell，旨在解决Thompson shell 中的脚本限制。（Chet Ramey 是自 1990 年以来 Bash 语言的主要维护者，在这一集的《代码英雄》中讨论了它）。作为 Unix 系统的一部分，这是这个来自贝尔实验室的技术的自然演变。Bourne 打算做什么不同的事情？研究员 M. Jones 很好地概述了它：Bourne shell 有两个主要目标：作为命令解释器以交互方式执行操作系统的命令，和用于脚本编程（编写可通过 shell 调用的可重用脚本）。除了替换 Thompson shell，Bourne shell 还提供了几个优于其前辈的优势。Bourne 将控制流、循环和变量引入脚本，提供了更具功能性的语言来（以交互式和非交互式）与操作系统交互。该 shell 还允许你使用 shell 脚本作为过滤器，为处理信号提供集成支持，但它缺乏定义函数的能力。最后，它结合了我们今天使用的许多功能，包括命令替换（使用后引号）和 HERE 文档（以在脚本中嵌入保留的字符串文字）。Bourne 在之前的一篇采访中这样描述它：最初的 shell （编程语言）不是一种真正的语言；它是一种记录 —— 一种从文件中线性执行命令序列的方法，唯一的控制流的原语是 GOTO 到一个标签。Ken Thompson 所编写的这个最初的 shell 的这些限制非常重要。例如，你无法简单地将命令脚本用作过滤器，因为命令文件本身是标准输入。而在过滤器中，标准输入是你从父进程继承的，不是命令文件。最初的 shell 很简单，但随着人们开始使用 Unix 进行应用程序开发和脚本编写，它就太有限了。它没有变量、它没有控制流，而且它的引用能力非常不足。对于脚本编写者来说，这个新 shell 是一个巨大的进步，但前提是你可以使用它。以自由软件来重新构思 Bourne Shell在此之前，这个占主导地位的 shell 是由贝尔实验室拥有和管理的专有软件。幸运的话，你的大学可能有权访问 Unix shell。但这种限制性访问远非自由软件基金会（FSF）想要实现的世界。Richard Stallman 和一群志同道合的开发人员那时正在编写所有的 Unix 功能，其带有可以在 GNU 许可证下免费获得的许可。其中一个开发人员的任务是制作一个 shell，那位开发人员是 Brian Fox。他对他的任务的讲述十分吸引我。正如他在播客上所说：它之所以如此具有挑战性，是因为我们必须忠实地模仿 Bourne shell 的所有行为，同时允许扩展它以使其成为一个供人们使用的更好工具。而那时也恰逢人们在讨论 shell 标准是什么的时候。在这一历史背景和将来的竞争前景下，流行的 Bourne shell 被重新构想，并再次重生。重新打造 Bourne Shell自由软件的使命和竞争这两个催化剂使重制的 Bourne shell（Bash）具有了生命。和之前不同的是，Fox 并没有把 shell 放到自己的名字之后命名，他专注于从 Unix 到自由软件的演变。（虽然 Fox Shell 这个名字看起来要比 Fish shell 更适合作为 fsh 命令 #missedopportunity）。这个命名选择似乎符合他的个性。正如 Fox 在剧集中所说，他甚至对个人的荣耀也不感兴趣；他只是试图帮助编程文化发展。然而，他并不是一个优秀的双关语。而 Bourne 也并没有因为他命名 shell 的文字游戏而感到被轻视。Bourne 讲述了一个故事，有人走到他面前，并在会议上给了他一件 Bash T 恤，而那个人是 Brian Fox。Shell发布于创造者Thompson Shell1971Ken ThompsonBourne Shell1977Stephen BourneBourne-Again Shell1989Brian Fox随着时间的推移，Bash 逐渐成长。其他工程师开始使用它并对其设计进行改进。事实上，多年后，Fox 坚定地认为学会放弃控制 Bash 是他一生中最重要的事情之一。随着 Unix 让位于 Linux 和开源软件运动，Bash 成为开源世界的至关重要的脚本语言。这个伟大的项目似乎超出了单一一个人的愿景范围。我们能从 shell 中学到什么？shell 是一项技术，它是笔记本电脑日常使用中的一个组成部分，你很容易忘记它也需要发明出来。从 Thompson 到 Bourne 再到 Bash，shell 的故事为我们描绘了一些熟悉的结论：有动力的人可以在正确的使命中取得重大进展。我们今天所依赖的大部分内容都建立在我们行业中仍然活着的那些传奇人物打下的基础之上。能够生存下来的软件超越了其原始创作者的愿景。 代码英雄在全部的第三季中讲述了编程语言，并且正在接近它的尾声。请务必订阅，来了解你想知道的有关编程语言起源的各种内容，我很乐意在下面的评论中听到你的 shell 故事。via: https://opensource.com/19/9/command-line-heroes-bash作者：Matthew Broberg 选题：lujun9972 译者：wxy 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
为什么 BASIC 是一种备受喜爱的入门语言？下一代该如何学习编程？《Command Line Heroes》 第三季的第二集今天抵达了，它对我的入门编程的怀旧让我回到了过去。（LCTT 译注：《Command Line Heroes》 是红帽公司制作的播客，讲述了开发人员、程序员、黑客、极客和开源反叛者如何彻底改变技术前景的真实史诗。其第一季制作于 2017 年，邀请到了谷歌、NASA 等重量级企业的技术专家担当嘉宾，讲述操作系统战争风云、美国航天局如何开源等等，涉及开源、操作系统、容器、DevOps、云计算等话题。）语言会影响可访问性这一集告诉我，BASIC 是计算机的理解力民主化的一次巨大飞跃。我很难想象，在一个不太遥远的、计算机尚且是稀罕之物的时代，是 BASIC 改变了世界。正如 Saron Yitbarek 提到的那样，“在早些年编程，你几乎得有个博士学位才行。”BASIC 是一个巨大的飞跃，它专注于可用性（适合初学者的命令）和资源共享（单个计算机的分时操作）。它使得编程不在局限于当时的“计算机玩家”（我喜欢这集中的这句话），并帮助了新一代人参与了进来。进入编程领域的壁垒得以下降。入门编程语言这一集的核心话题是围绕学习入门语言展开的。关于学习什么编程语言以及如何学习，有很多建议。关于这个问题在这里已经写了很多。我喜欢听到 Saron 以 Ruby 作为她的介绍的故事，以及它以一种几乎意想不到的方式变得有趣。我有一些类似的经历，因为我在一些项目中用到了 Ruby。它的灵活性让我感到开心。当我（对编程）感到紧张时，正是这种快乐让我重新回到它的身边，并且它有一些能够使语言如此充满情感的强大功能。我第一次体验编程是用 HTML 和 CSS，但我第一个重型编程语言是 Java。我永远不会忘记在课堂的第一天被告知要记住 public static void main，但没有告知我关于它意味着什么的任何信息。我们花了很多时间在面向对象编程的上下文环境中探讨它是什么，但它从未像我在 Ruby 中使用 .each 迭代列表，或者像在 Python 中用 import numpy 做一些数学魔术那样感到兴奋。然后我听说孩子们正在学习如何使用 Python 编写 Minecraft 或使用像 Scratch 这样的可视化编程语言，我因此而悟，BASIC 的遗产正在以新的方式存在。我从这一集中获取到的内容：请记住，没有人出生就是程序员。每个人都没有这样的背景。你并不孤单。学习一门语言。任何一种都行。如果你有选择的可能，那么请选择能带给你最大乐趣的那个。不要忘记所有语言都可以构建一些东西。请为人类创造有意义的事物。《Command Line Heroes》整个第三季将涉及编程语言。请在此处订阅来学习你想要了解的有关编程语言的起源，我很乐意在下面的评论中听到你的想法。via: https://opensource.com/19/7/command-line-heroes-ruby-basic作者：Matthew Broberg 选题：lujun9972 译者：wxy 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出