如果你的手机有一个解锁的 bootloader 的话，你可以用 fastboot 命令来刷入原厂镜像。听起来这好像是外行弄不懂的东西，但是当你需要升级被 root 过的设备，修理坏掉的手机，恢复到原生系统，或者是比别人更早的享受 Android 更新时，它可是最好的办法。

和 ADB 类似，fastboot 是一个强大的 Android 命令行工具。这听起来可能会很恐怖 —— 别担心，一旦你了解了它，你就会知道 Android 的内部工作原理，以及如何解决最常见的问题。

关于三星设备的注释

下面的指南对于 Nexus、Pixel、HTC 以及 Motorola 的大多数设备，以及其他众多厂商的手机和平板电脑都适用。但是，三星的设备有自己的刷机软件，所以你的 Galaxy 设备并不支持 Fastboot。对于三星的设备，最好使用 Odin 来进行刷机工作，我们在下文的链接中提供了相关指南。

第一步 在你的电脑上安装 ADB 和 Fastboot

首先，你需要在你的电脑上安装 ADB 和 Fastboot，只有有了它们你才能使用 Fastboot 命令刷入镜像。网上有不少“一键安装版”或者“绿色版”的 ADB 和 Fastboot，但是我不建议安装这样的版本，它们没有官方版本更新那么快，所以可能不会完全兼容新版设备。

你最好从 Google 上安装 Android SDK Tools。这才是“真正的” ADB 和 Fastboot。安装 SDK Tools 可能需要一点时间，不过这等待是值得的。在下面的 方法 1 中，我会说明在 Windows, Mac,以及 Linux 中安装这个软件的方法，所以可以跳转到那里开始。

第二步 OEM 解锁 OEM Unlocking

为了能够使用 Fastboot 刷入镜像，你需要解锁你设备的 bootloader。如果你已经解锁，你可以跳过这步到第三步。

如果你的设备的 Android 版本在 6.0 及以上的话，在你解锁 bootloader 之前，你还需要开启一项设置。首先你需要开启 开发者选项 Developers Options 。开启之后，进入“开发者选项菜单”，然后开启 “OEM 解锁” 选项。之后就可以进行下一步了。

如果你的设备没有这个选项，那么你的设备的 Android 版本可能不是 6.0 或以上。如果这个选项存在但是是灰色的，这就意味着你的 bootloader 不能解锁，也就是说你不能使用 Fastboot 给你的手机刷入镜像。

第三步 进入 Bootloader 模式

在使用 Fastboot 软件之前，你还需要让你的设备进入 bootloader 模式。具体进入方式与你的设备有关。

对于大多数手机，你需要先完全关闭你的手机。在屏幕黑掉以后，同时按住开机键和音量向下键大约 10 秒。

如果这不起效的话，关掉手机，按住音量降低键。然后把手机用 USB 数据线连到电脑上，等上几秒钟。

如果还不起效的话，改按音量升高键，再试试第二种方法。

很快你就会看见像这样的 bootloader 界面：

看到这个界面之后，确保你的设备已经连接到电脑上。之后的工作就都是在电脑上完成了，把手机放在那里就成。

第四步 在你的电脑上为 ADB 打开一个命令行窗口

转到 ADB 和 Fastboot 的安装目录。对于 Windows 用户来说，这目录通常是 C:\Program Files (x86)\Android\android-sdk\platform-tools。 对于 Mac 和 Linux 用户，则取决于你安装此工具时将 ADB 解压的位置，所以如果你忘了位置的话，就在硬盘里搜索 platform-tools。

在安装目录下，如果你使用 Windows PC 的话，按住键盘上的 Shift 键，在文件管理器的空白处单击右键，然后选择“在此处开启命令行窗口”。如果你用的是 Mac 或者 Linux，那么你仅仅需要打开一个终端，然后转到 platform-tools 下。

第五步 解锁 bootloader

这一步你仅仅需要做一次，所以如果你的 bootloader 已经解锁，你可以直接跳过这步。否则你还需要运行一条命令 —— 注意，这条命令会清空你设备上的所有数据。

在输入命令之前，我需要说明下，下面的命令仅仅对 Windows 适用，Mac 用户需要在每条命令前加上一个句号和一个斜线(./)，Linux 用户则需要加上一个斜线(/)。

所以，在 ADB Shell 里输入如下命令，然后按下回车键。

fastboot devices

如果程序输出了以 fastboot 结尾的一串字符，那就说明你的设备连接正常，可以继续操作。如果没有的话，回到第一步，检查你的 ADB 以及 Fastooot，是否正确安装，之后再确定设备是否如第三步所示进入了 bootloader 模式。

之后，解锁你的 bootloader。因为 Android 版本的差别，我们有两种方法来解决这个问题。

如果你的设备的 Android 版本是 5.0 或者更低版本 ，输入如下命令：

fastboot oem unlock

如果你的 Android 版本是 6.0 或更高的话，输入如下命令，然后按下回车：

fastboot flashing unlock

将解锁命令发送到 6.0 或者更高版本的 Android 手机上

这时，你的 Android 手机会问你是否确定要解锁 bootloader。确定你选中了 “Yes” 的选项，如果没有，使用音量键选中 “Yes”。然后按下电源键，你的设备将会开始解锁，之后会重启到 Fastboot 模式。

Nexus 6P 上的解锁菜单。图像来自 Dallas Thomas/Gadget Hacks

第六步 下载出厂镜像

现在你的 bootloader 已经解锁，准备好刷入出厂镜像了 -- 不过，你需要先下载镜像。下面是常规设备下载出厂镜像的链接。

• Nexus 或 Pixel 设备的出厂镜像
• HTC 设备出厂镜像
• Motorola 设备出厂镜像

使用上面的链接，在列表中定位你的设备型号，然后下载最新固件到计算机上。如果你的厂商不在列表中，可以试着用 “factory images for ” 进行 google 搜索。

第七步 刷入出厂镜像

现在该刷入镜像了。首先将从厂商网站下载的出厂镜像文件解压。我推荐 7-Zip ，它是免费的，支持大多数格式。

解压出厂镜像

下一步，把压缩包中内容移动到你的 ADB 安装文件夹。之后在这里打开一个命令行窗口。要得到更多信息，请回看第四步。

出厂镜像移动到 platform-tools 的文件

除了上面这些，你有两种刷入镜像的方法。我会在下文分开叙述。

方法一：使用 flash-all 脚本

大多数出厂镜像都会包含一个flash-all 脚本，可以让你一条命令就完成刷机过程。如果你试图让你的黑砖恢复正常的话，这是最简单的方法。但是这会让你的手机回到未 root 的状态，并会擦除所有数据，如果你不想这样的话，请选择方法二。

如果要运行 flash-all 脚本，输入如下命令，之后敲下回车：

flash-all

运行 "flash-all" 命令

这需要一点时间，当这步完成之后，你的手机应当自动重启，你可以享受 100% 原生固件。

方法二 手动解压刷入镜像

你可以手动刷入系统镜像。这么做需要额外的工作，但是它可以在不清除数据的情况下反 root，升级设备，或者救回你的砖机。

首先解压出厂镜像包中的所有压缩文件。通常压缩包里会包含三或四个层叠的文件夹，确认你已经解压了所有的压缩文件。之后把这些文件移动到 platform-tools —— 或者说，别把他们放到任何子文件夹下。

从出厂镜像包解压后的所有文件移至 platform-tools 目录

在这些文件里，有两个镜像是可以直接删除的：cache.img 和 userdata.img。就是这两个文件清除了你的设备数据，如果你不刷入这两个镜像，你的数据就不会消失。

在剩下的文件中，有六个镜像构成了 Android 的核心部分： boot、bootloader、 radio、 recovery、 system 和 vendor。

boot 镜像包含了内核，如果你想要换掉一个不太好用的自制内核的话，你仅仅需要刷入这个文件。通过键入如下命令完成工作：

fastboot flash boot <boot image file name>.img

下一个就是 bootloader 镜像—— 也就是你用来刷入镜像的界面。如果你要升级 bootloader 的话，输入如下命令：

fastboot flash bootloader <bootloader image file name>.img

做完这步之后，你就可以用新版的 bootloader 刷入镜像。要想如此，输入：

fastboot reboot-bootloader

之后就是 radio 镜像。这个镜像控制你设备的网络连接，如果你手机的 Wi-Fi 或者移动数据出现了毛病，或者你仅仅想升级你的 radio，输入：

fastboot flash radio <radio image file name>.img

然后就是 recovery。根据你之前的修改，你可能选择刷或不刷这个镜像。例如，如果你已经刷入 TWRP 的话，刷入这个镜像覆盖你的修改，并替代为 stock recovery。如果你仅仅要升级你的已经被修改过的设备，你就可以跳过这步。如果你想要新版的 stock recovery ，键入：

fastboot flash recovery <recovery file name>.img

下一个可是个大家伙：system 镜像，它包含了 Android 系统所需的全部文件。它是升级过程中最重要的部分。

如果你不想升级系统，仅仅是要换回原生固件或者是救砖的话，你只需要刷入这个镜像，它包含了 Android 的所有文件。换言之，如果你仅仅刷入了这个文件，那你之前对这个设备做的修改都会被取消。

作为一个救砖的通用方法，以及升级 Android 的方法，键入：

fastboot flash system <system file name>.img

最后，就是 vendor 镜像。只有新版的设备才包含这个包。没有的话也不必担心，不过如果有这个文件的话，那它就包含了一些重要的文件，键入如下命令使其更新：

fastboot flash vendor <vendor file name>.img

在这之后，你就可以重新启动设备：

fastboot reboot

手动逐个刷入出厂镜像

至此，你的设备已经完全更新，如果你是救砖的话，你的手机应该已经完好的运行。如果你知道每个系统镜像怎么是干什么的话，你就会更好的理解 Android 是怎么运行的。

手动刷入镜像比做任何修改已经帮助我更多地理解了 Android。你会发现，Android 就是写进存储设备里的一堆镜像，现在你可以自己处理他们，你也能更好的处理有关 root 的问题。

• 在Facebook、Twitter、Google+ 以及 YouTube 关注 Gadget Hacks
• 在 Facebook、Twitter 和 Pinterest 上关注 Android Hacks
• 在 Facebook、Twitter、 Pinterest 还有 Google+ 上关注 WonderHowTo

via: http://android.wonderhowto.com/how-to/complete-guide-flashing-factory-images-using-fastboot-0175277/

作者：Dallas Thomas 译者：name1e5s 校对：jasminepeng

本文由 LCTT 组织编译，Linux中国 荣誉推出

如果你要换一部手机或升级你的系统，备份你的数据就变得至关重要。我们存储重要数据的位置之一就是我们的短信/彩信，不管是感情价值还是实用价值，备份它们是很有用的。

然而，不像照片、视频或音频文件可以相对容易地传输和备份，备份短信/彩信比较复杂，通常需要使用第三方 app 或服务。

为什么要手动备份

尽管现在有很多不同的 app 能够帮你备份短信/彩信，你可能因为以下原因，考虑自己动手备份它们：

1. app 可能不能在所有的设备和安卓版本上都工作。
2. app 可能把你的备份数据上传到云端， 有破坏你的内容安全的风险。
3. 通过手动备份，你可以完全掌握你的数据通过哪里，走向哪里，备份过程中减少被间谍软件窥视的危险。
4. 手动备份相比其他方法更省时，更省力，更直接。

怎么手动备份短信/彩信？

要手动备份你的短信/彩信，你需要在你的电脑上安装一个叫做 adb 的安卓工具。

现在，需要重点知道的是，安卓把短信/彩信通常存储在一个叫做 mmssms.db 的数据库里。

因为在不同设备上这个数据库的位置可能不相同，而且，其他短信 app 会创建它们自己的数据库，比如 GO SMS 会创建 gommssms.db 数据库， 所以你需要做的第一件事是搜索这些数据库。

打开命令行工具（我使用了 Linux Terminal， 你也可以使用 Windows CMD 或 PowerShell ）并运行以下命令：

注意： 以下是完成该任务的一系列命令，再后面是每个命令用途的解释。

adb root
adb shell
find / -name "*mmssms*"
exit

adb pull /PATH/TO/mmssms.db /PATH/TO/DESTINATION/FOLDER

解释

一开始我们使用 adb root 命令来以 root 模式启动 adb － 这样我们就有了读取系统保护文件的权限。

adb shell 用来进入设备的 shell。

然后， find 命令用来搜索数据库。（在我的例子中，我发现数据库在 /data/data/com.android.providers.telephony/databases/mmssms.db)

建议：如果你的终端输出了太多无关的结果，可以试试使用 find 的参数来精简结果。(具体参数可以搜索引擎查下)

安卓短信/彩信数据库

然后我们使用 exit 命令回退到我们的本地系统目录。

最后，使用 adb pull 把数据库文件复制到我们电脑的一个文件夹里。

现在，当你想要还原短信/彩信时，不管是还原到新的设备还是新的系统版本， 只要再次搜索新系统中短信/彩信的具体位置，并用我们备份的数据库替换它即可。

使用 adb push 来替换它，例如：

adb push ~/Downloads/mmssms.db /data/data/com.android.providers.telephony/databases/mmssms.db

via: https://iwf1.com/how-to-manually-backup-your-sms-mms-messages-on-android/

作者：Liron 译者：willcoderwang 校对：jasminepeng

本文由 LCTT 原创编译，Linux中国 荣誉推出

这篇文章针对开发和部署基于 JavaScript 的应用（服务器端的 Node.js 或者客户端）的各种经验水平的开发者，通过本文，你将看到如何把 AWS SDK， Amazon Cognito Identity SDK 嵌入到 JavaScript 中，以及如何使用流行的 webpack 模块打包器。

2016 年 7 月， AWS 推出了 Amazon Cognito 用户库 （ user pool ） ，这个新特性极大的方便了开发者在移动和 Web 应用程序上添加注册和登录功能。为了让开发者更容易在自己的应用程序中实现用户库功能，我们也发布了用于 JavaScript 的 Amazon Cognito Identity SDK。

Amazon Cognito 用户库可以让你在移动和 Web 应用程序上添加用户注册和登录功能更加容易。全托管用户库可以扩展到数以百万计的用户，你可以在每个 AWS 账户下有多重目录。创建一个用户库只需要几分钟的时间，并且你可以决定当一个新用户在你的应用程序或服务上注册时哪些属性（包括地址、邮箱、电话号码以及自定义属性）是强制的，哪些是可选择的。你的应用程序也可以指定所需的密码强度，指定用户需要进行多因素认证（MFA），以及通过电话号码或者邮件地址来验证新用户，从而进一步加强应用程序的安全性。

如果你是首次接触用于 JavaScript 的 Amazon Cognito Identity SDK，那么请先阅读这篇 AWS 文章作为开始。

为什么在 JavaScript 上使用 Asset 及模块捆绑的 Amazon Cogtito Identity SDK

今天，针对移动和桌面的现代 Web 应用程序都能为用户提供安全、快捷、灵敏以及类本地应用的体验。毫无疑问，现代的浏览器功能足够强大，能够肩负起大量可能的功能实现。许多流行的实现很大程度上依赖于 JavaScript 应用程序通过某种形式的 asset 封装和/或模块捆绑进行部署。这使得许多开发人员能够很好的维护自己的 JavaScript 应用程序，并且可以通过使用 script 标签创建一个或多个可以加载到客户端浏览器上的文件。

关于如何实现打包有许多争鸣，包括 Grunt 和 Gulp 这样的 task runner，以及 Browserity 这样的打包器。然而，一个普遍的共识是， asset 打包不仅可以改善加载时间 - 它可以在确保可测试性和健壮性的前提下使你的应用程序模块化。

使用带有 Amazon Cognito Identity SDK 的 webpack 打包 JavaScript

我们接到了许多请求，要求我们提供如何在 webpack 环境下整合用于 JavaScript 的 Amazon Cognito Identity SDK 的更多细节。我们特地要求确保 webpack 正确管理一下第三方的依赖包：

• 用于 BigInteger 计算的 JavaScript BN 库（jsbn）
• jsbn 扩展及包含大多数公共 BigInteger 方法的其它 jsbn 方法（jsbn2）
• Stanford JavaScript Crypto 库（jscl）

通过这些例子，可以看到，下面这些 bower 库都被 bower.json 使用

"aws-cognito-sdk": "https://raw.githubusercontent.com/aws/amazon-cognito-identity-js/master/dist/aws-cognito-sdk.js",
"amazon-cognito-identity": "https://raw.githubusercontent.com/aws/amazon-cognito-identity-js/master/dist/amazon-cognito-identity.min.js",
"sjcl": "https://raw.githubusercontent.com/bitwiseshiftleft/sjcl/master/sjcl.js",
"jsbn": "https://raw.githubusercontent.com/andyperlitch/jsbn/master/index.js",

出于我们前面给出的关于 asset 打包对于开发过程的重要性的原因，除非你的应用程序非常小，否则使用像 webpack 这样的 asset 打包工具几乎总是必须的。当然，还有一个方法是可以通过使用标签简单的处理所有依赖关系。然而，这会污染全局命名空间，而且不能够提供最优的资源管理和加载方式。许多开发者首次使用的是具有标准 babel 加载器的标准 webpack.config.js 文件，像下面展示的这样。

{
  /** test for file ending in js or jsx 
   * exclude node_module and bower_components - we dont want to babel these 
   * use the babel loader 
   * apply the react and es2015 (es6) transformations **/

  test: /\.jsx?$/,
  exclude: /(node_modules|bower_components)/,
  loader: 'babel',
  query: {
    presets: ['react', 'es2015']
  }
}

需要重点记住的是，这个配置没有考虑一些第三方依赖关系，这些被用于 JavaScript 的 Amazon Cognito Identity SDK 所使用的第三方依赖目前没有使用 JavaScript 通用模块定义(UMD)。

UMD 模式试图提供与 RequireJS 和 CommonJS 这些当前最流行的脚本加载器的异步模块定义 [AMD] 的基本兼容。

这是 webpack 所依赖的模式，为了让 webpack 能够工作，我们必须进行一些改变。不做这些改变，你可能会遇到下面这些错误。

amazon-cognito-identity.min.js:19 Uncaught ReferenceError: BigInteger is not defined

这样一个错误可能会在调用 AWSCognito.CognitoIdentityServiceProvider.CognitoUser property authenticateUser 的时候出现。在这个错误例子中，我们可以利用 webpack 的 import 和 export 加载器的能力来解决这个错误。

使用 webpack 加载器

根据 [webpack 文档]，“加载器允许你通过 require() 或 load 来预处理文件。加载器是一种类似其它构建工具中 “tasks” 的工具，它可以提供一个处理前端构建步骤的强大方法。加载器可以把一个文件从一种语言转化成另一种语言，比如把 CoffeeScript 转化成 JavaScript ，或者把图像转换为 data URL。“

为了解决 UMD 的兼容性缺乏的问题，你必须依赖两个具体的加载器， import 和 export 加载器。

使用 export 加载器

在使用用于 JavaScript 的 Amazon Cognito Identity SDK 的情况下，我们需要确保把 theAWSCognito 变量导出到 require /import 它们的模块的变量范围内（针对 ES6）。

{
  test: /aws-cognito-sdk\/index\.js/,
  loader: 'exports?AWSCognito'
}

在由 webpack 创建的捆绑中，使用 export 加载器会有导出模块方法的效果。因此， 在 require 和 import 后，AWSCognito 和 AWS 是可访问的（针对 ES6）。

var AWSCognito = require('aws-cognito-sdk')

/*** EXPORTS from export-loader ***/ 
module.exports = AWSCongito

这儿可以找到更多关于 export 加载器的信息。

使用 import 加载器

import 加载器主要用于把变量注入（import）到另一个模块的变量范围内。当第三方模块需要依赖全局变量的时候， import 加载器非常有用，比如针对 JavaScript 的 Amazon Cognito Identity SDK 需要依赖 BigInteger 或者 sjcl 的时候。

如果你不使用 webpack 加载器，下面这些内容会在一个捆绑中生成。

__webpack_require__(431);       // refers to jsbin
__webpack_require__(432);       // refers to sjcl

因为 jsbin 和 sjcl 都不能 export 任何东西，因此任何依赖于这些模块的调用都会导致一个错误。

为了解决这个问题，我们需要使用下面的 webpack 加载器配置：

{
  test: /amazon-cognito-identity\/index\.js/,
  loader: 'imports?jsbn,BigInteger=>jsbn.BigInteger,sjcl'
},
{
  test: /sjcl\/index\.js/,
  loader: 'imports?sjcl'
}

这个配置把下面的这些内容嵌入到了由 webpack 创建的捆绑中（此时是 bundle.js）。

/*** IMPORTS FROM imports-loader ***/
var jsbn = __webpack_require__(431);
var BigInteger = jsbn.BigInteger;
var sjcl = __webpack_require__(432);

结果，jsbn、BigInteger 和 sjcl 都被从它们各自的模块中导入到了用于 JavaScript 的 Amazon Cognito Identity SDK 中。

有关 import 加载器的更多信息可以在这儿找到。

下一步

我们鼓励你下载用于 JavaScript 的 Amazon Cognito Identity SDK 并开始构建你的应用，并在这篇文章的指导下通过 webpack 能够迅速掌握。

如果你有任何意见或问题，请在下面自由评论，也可以发邮件到 [email protected] 或者在这儿提出问题。

引用

这篇文章引用了下面这些第三方资源：

• webpack - https://webpack.github.io/
• webpack 文件 - http://webpack.github.io/docs/what-is-webpack.html
• webpack export 加载器 - https://github.com/webpack/exports-loader
• webpack import 加载器 - https://github.com/webpack/imports-loader
• 用于 BigInteger 计算的 JavaScript BN 库- http://www-cs-students.stanford.edu/~tjw/jsbn/jsbn.js
• jsbns - http://www-cs-students.stanford.edu/~tjw/jsbn/jsbn2.js
• Stanford JavaScript Crypto 库 - https://github.com/bitwiseshiftleft/sjcl
• RequireJS - http://requirejs.org/
• CommonJS - http://www.commonjs.org/

via: https://mobile.awsblog.com/post/Tx1A84CLMDJ744T/Using-webpack-with-the-Amazon-Cognito-Identity-SDK-for-JavaScript

作者：Marc Teichtahl 译者：ucasFL 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

最近我开始发力钻研 Python 的新 asyncio 模块。原因是我需要做一些事情，使用事件 IO 会使这些事情工作得更好，炙手可热的 asynio 正好可以用来牛刀小试。从试用的经历来看，该模块比我预想的复杂许多，我现在可以非常肯定地说，我不知道该如何恰当地使用 asyncio。

从 Twisted 框架借鉴一些经验来理解 asynio 并非难事，但是，asyncio 包含众多的元素，我开始动摇，不知道如何将这些孤立的零碎拼图组合成一副完整的图画。我已没有足够的智力提出任何更好的建议，在这里，只想分享我的困惑，求大神指点。

原语

asyncio 通过 协程 coroutines 的帮助来实现异步 IO。最初它是通过 yield 和 yield from 表达式实现的一个库，因为 Python 语言本身演进的缘故，现在它已经变成一个更复杂的怪兽。所以，为了在同一个频道讨论下去，你需要了解如下一些术语：

• 事件循环
• 事件循环策略
• awaitable
• 协程函数
• 老式协程函数
• 协程
• 协程封装
• 生成器 （ generator ）
• future
• 并发的future
• 任务 （ task ）
• 句柄
• 执行器 （ executor ）
• 传输 （ transport ）
• 协议

此外，Python 还新增了一些新的特殊方法：

• __aenter__ 和 __aenter__，用于异步块操作
• __aiter__ 和 __anext__，用于异步迭代器（异步循环和异步推导）。为了更强大些，协议已经改变过一次了。 在 Python 3.5 它返回一个 awaitable（这是个协程）；在 3.6它返回一个新的异步生成器。
• __await__，用于自定义的 awaitable

你还需要了解相当多的内容，文档涵盖了那些部分。尽管如此，我做了一些额外说明以便对其有更好的理解：

事件循环

asyncio 事件循环和你第一眼看上去的略有不同。表面看，每个线程都有一个事件循环，然而事实并非如此。我认为它们应该按照如下的方式工作：

• 如果是主线程，当调用 asyncio.get_event_loop() 时创建一个事件循环。
• 如果是其它线程，当调用 asyncio.get_event_loop() 时返回运行时错误。
• 当前线程可以使用 asyncio.set_event_loop() 在任何时间节点绑定事件循环。该事件循环可由 asyncio.new_evet_loop() 函数创建。
• 事件循环可以在不绑定到当前线程的情况下使用。
• asyncio.get_event_loop() 返回绑定线程的事件循环，而非当前运行的事件循环。

这些行为的组合是超混淆的，主要有以下几个原因。 首先，你需要知道这些函数被委托到全局设置的底层事件循环策略。 默认是将事件循环绑定到线程。 或者，如果需要的话，可以在理论上将事件循环绑定到一个 greenlet 或类似的。 然而，重要的是要知道库代码不控制策略，因此不能推断 asyncio 将适用于线程。

其次，asyncio 不需要通过策略将事件循环绑定到上下文。 事件循环可以单独工作。 但是这正是库代码的第一个问题，因为协同程序或类似的东西并不知道哪个事件循环负责调度它。 这意味着，如果从协程中调用 asyncio.get_event_loop()，你可能没有机会取得事件循环。 这也是所有 API 均采用可选的显式事件循环参数的原因。 举例来说，要弄清楚当前哪个协程正在运行，不能使用如下调用：

def get_task():
    loop = asyncio.get_event_loop()
    try:
        return asyncio.Task.get_current(loop)
    except RuntimeError:
        return None

相反，必须显式地传递事件循环。 这进一步要求你在库代码中显式地遍历事件循环，否则可能发生很奇怪的事情。 我不知道这种设计的思想是什么，但如果不解决这个问题（例如 get_event_loop() 返回实际运行的事件循环），那么唯一有意义的其它方案是明确禁止显式事件循环传递，并要求它绑定到当前上下文（线程等）。

由于事件循环策略不提供当前上下文的标识符，因此库也不可能以任何方式“索引”到当前上下文。 也没有回调函数用来监视这样的上下文的拆除，这进一步限制了实际可以开展的操作。

awaitable 与 协程 coroutine

以我的愚见，Python 最大的设计错误是过度重载迭代器。它们现在不仅用于迭代，而且用于各种类型的协程。 Python 中迭代器最大的设计错误之一是如果 StopIteration 没有被捕获形成的空泡。 这可能导致非常令人沮丧的问题，其中某处的异常可能导致其它地方的生成器或协同程序中止。 这是一个长期存在的问题，基于 Python 的模板引擎如 Jinja 经常面临这种问题。 该模板引擎在内部渲染为生成器，并且当由于某种原因的模板引起 StopIteration 时，渲染就停止在那里。

Python 慢慢认识到了过度重载的教训。 首先在 3.x 版本加入 asyncio 模块，并没有语言级支持。 所以自始至终它不过仅仅是装饰器和生成器而已。 为了实现 yield from 以及其它东西，StopIteration 再次重载。 这导致了令人困惑的行为，像这样：

>>> def foo(n):
...  if n in (0, 1):
...   return [1]
...  for item in range(n):
...   yield item * 2
...
>>> list(foo(0))
[]
>>> list(foo(1))
[]
>>> list(foo(2))
[0, 2]

没有错误，没有警告。只是不是你所期望的行为。 这是因为从一个作为生成器的函数中 return 的值实际上引发了一个带有单个参数的 StopIteration，它不是由迭代器协议捕获的，而只是在协程代码中处理。

在 3.5 和 3.6 有很多改变，因为现在除了生成器我们还有协程对象。除了通过封装生成器来生成协程，没有其它可以直接生成协程的单独对象。它是通过用给函数加 async 前缀来实现。 例如 async def x() 会产生这样的协程。 现在在 3.6，将有单独的异步生成器，它通过触发 AsyncStopIteration 保持其独立性。 此外，对于Python 3.5 和更高版本，导入新的 future 对象（generator_stop），如果代码在迭代步骤中触发 StopIteration，它将引发 RuntimeError。

为什么我提到这一切？ 因为老的实现方式并未真的消失。 生成器仍然具有 send 和 throw 方法以及协程仍然在很大程度上表现为生成器。你需要知道这些东西，它们将在未来伴随你相当长的时间。

为了统一很多这样的重复，现在我们在 Python 中有更多的概念了：

• awaitable：具有__await__方法的对象。 由本地协同程序和旧式协同程序以及一些其它程序实现。
• 协程函数 （ coroutinefunction ） ：返回原生协程的函数。 不要与返回协程的函数混淆。
• 协程 （ coroutine ） : 原生的协程程序。 注意，目前为止，当前文档不认为老式 asyncio 协程是协程程序。 至少 inspect.iscoroutine 不认为它是协程。 尽管它被 future/awaitable 分支接纳。

特别令人困惑的是 asyncio.iscoroutinefunction 和inspect.iscoroutinefunction 正在做不同的事情，这与 inspect.iscoroutine 和 inspect.iscoroutinefunction 情况相同。 值得注意的是，尽管 inspect 在类型检查中不知道有关 asycnio 旧式协程函数的任何信息，但是当您检查 awaitable 状态时它显然知道它们，即使它与 **await** 不一致。

协程封装器 coroutine wrapper

每当你运行 async def ，Python 就会调用一个线程局部的协程封装器。它由 sys.set_coroutine_wrapper 设置，并且它是可以包装这些东西的一个函数。 看起来有点像如下代码：

>>> import sys
>>> sys.set_coroutine_wrapper(lambda x: 42)
>>> async def foo():
...  pass
...
>>> foo()
__main__:1: RuntimeWarning: coroutine 'foo' was never awaited
42

在这种情况下，我从来没有实际调用原始的函数，只是给你一个提示，说明这个函数可以做什么。 目前我只能说它总是线程局部有效，所以，如果替换事件循环策略，你需要搞清楚如何让协程封装器在相同的上下文同步更新。创建的新线程不会从父线程继承那些标识。

这不要与 asyncio 协程封装代码混淆。

awaitable 和 future

有些东西是 awaitable 的。 据我所见，以下概念被认为是 awaitable：

• 原生的协程
• 配置了假的 CO_ITERABLE_COROUTINE 标识的生成器（文中有涉及）
• 具有 __await__ 方法的对象

除了生成器由于历史遗留的原因不使用之外，其它的对象都使用 __await__ 方法。 CO_ITERABLE_COROUTINE 标志来自哪里？它来自一个协程封装器（现在与 sys.set_coroutine_wrapper 有些混淆），即 @asyncio.coroutine。 通过一些间接方法，它使用 types.coroutine（现在与 types.CoroutineType 或 asyncio.coroutine 有些混淆）封装生成器，并通过另外一个标志 CO_ITERABLE_COROUTINE 重新创建内部代码对象。

所以既然我们知道这些东西是什么，那么什么是 future？ 首先，我们需要澄清一件事情：在 Python 3 中，实际上有两种（完全不兼容）的 future 类型：asyncio.futures.Future 和 concurrent.futures.Future。 其中一个出现在另一个之前，但它们都仍然在 asyncio 中使用。 例如，asyncio.run_coroutine_threadsafe() 将调度一个协程到在另一个线程中运行的事件循环，但它返回一个 concurrent.futures.Future 对象，而不是 asyncio.futures.Future 对象。 这是有道理的，因为只有 concurrent.futures.Future 对象是线程安全的。

所以现在我们知道有两个不兼容的 future，我们应该澄清哪个 future 在 asyncio 中。 老实说，我不完全确定差异在哪里，但我打算暂时称之为“最终”。它是一个最终将持有一个值的对象，当还在计算时你可以对最终结果做一些处理。 future 对象的一些变种称为 deferred，还有一些叫做 promise。 我实在难以理解它们真正的区别。

你能用一个 future 对象做什么？ 你可以关联一个准备就绪时将被调用的回调函数，或者你可以关联一个 future 失败时将被触发的回调函数。 此外，你可以 await 它（它实现__await__，因此可等待），此外，future 也可以取消。

那么你怎样才能得到这样的 future 对象？ 通过在 awaitable 对象上调用 asyncio.ensure_future。它会把一个旧版的生成器转变为 future 对象。 然而，如果你阅读文档，你会读到 asyncio.ensure_future 实际上返回一个task（任务）。 那么问题来了，什么是任务？

任务

任务 （ task ） 某种意义上是一个封装了协程的 futur 对象。它的工作方式和 future 类似，但它也有一些额外的方法来提取所包含的协程的当前堆栈。 我们已经见过了在前面提到过的任务，因为它是通过 Task.get_current 确定事件循环当前正在做什么的主要方式。

在如何取消工作方面，任务和 future 也有区别，但这超出了本文的范围。“取消”是它们自己最大的问题。 如果你处于一个协程中，并且知道自己正在运行，你可以通过前面提到的 Task.get_current 获取自己的任务，但这需要你知道自己被派遣在哪个事件循环，该事件循环可能是、也可能不是已绑定的那个线程。

协程不可能知道它与哪个循环一起使用。task 也没有提供该信息的公共 API。 然而，如果你确实可以获得一个任务，你可以访问 task._loop，通过它反指到事件循环。

句柄

除了上面提到的所有一切还有句柄。 句柄是等待执行的不透明对象，不可等待，但可以被取消。 特别是如果你使用 call_soon 或者 call_soon_threadsafe（还有其它一些）调度执行一个调用，你可以获得句柄，然后使用它尽力尝试取消执行，但不能等待实际调用生效。

执行器 Executor

因为你可以有多个事件循环，但这并不意味着每个线程理所当然地应用多个事件循环，最常见的情形还是一个线程一个事件循环。 那么你如何通知另一个事件循环做一些工作？ 你不能到另一个线程的事件循环中执行回调函数并获取结果。 这种情况下，你需要使用执行器。

执行器 Executor 来自 concurrent.futures，它允许你将工作安排到本身未发生事件的线程中。 例如，如果在事件循环中使用 run_in_executor 来调度将在另一个线程中调用的函数。 其返回结果是 asyncio 协程，而不是像 run_coroutine_threadsafe 这样的并发协程。 我还没有足够的心智来弄清楚为什么设计这样的 API，应该如何使用，以及什么时候使用。 文档中建议执行器可以用于构建多进程。

传输和协议

我总是认为传输与协议也凌乱不堪，实际这部分内容基本上是对 Twisted 的逐字拷贝。详情毋庸赘述，请直接阅读相关文档。

如何使用 asyncio

现在我们已经大致了解 asyncio，我发现了一些模式，人们似乎在写 asyncio 代码时使用：

• 将事件循环传递给所有协程。 这似乎是社区中一部分人的做法。 把事件循环信息提供给协程为协程获取自己运行的任务提供了可能性。
• 或者你要求事件循环绑定到线程，这也能达到同样的目的。 理想情况下两者都支持。 可悲的是，社区已经分化。
• 如果想使用上下文数据（如线程本地数据），你可谓是运气不佳。 最流行的变通方法显然是 atlassian 的 aiolocals，它基本上需要你手动传递上下文信息到协程，因为解释器不为此提供支持。 这意味着如果你用一个工具类库生成协程，你将失去上下文。
• 忽略 Python 中的旧式协程。 只使用 3.5 版本中 async def 关键字和协程。 你总可能要用到它们，因为在老版本中，没有异步上下文管理器，这是非常必要的资源管理。
• 学习重新启动事件循环进行善后清理。 这部分功能和我预想的不同，我花了比较长的时间来厘清它的实现。清理操作的最好方式是不断重启事件循环直到没有等待事件。 遗憾的是没有什么通用的模式来处理清理操作，你只能用一些丑陋的临时方案糊口度日。 例如 aiohttp 的 web 支持也做这个模式，所以如果你想要结合两个清理逻辑，你可能需要重新实现它提供的工具助手，因为该助手功能实现后，它彻底破坏了事件循环的设计。 当然，它不是我见过的第一个干这种坏事的库 :(。
• 使用子进程是不明显的。 你需要一个事件循环在主线程中运行，我想它是在监听信号事件，然后分派到其它事件循环。 这需要通过 asyncio.get_child_watcher().attach_loop(...) 通知循环。
• 编写同时支持异步和同步的代码在某种程度上注定要失败。 尝试在同一个对象上支持 with 和 async with 是危险的事情。
• 如果你想给一个协程起个更好的名字，弄清楚为什么它没有被等待，设置 __name__没有帮助。 你需要设置 __qualname__ 而不是打印出错误消息来。
• 有时内部类型交换会使你麻痹。 特别是 asyncio.wait() 函数将确保所有的事情都是 future，这意味着如果你传递协程，你将很难发现你的协程是否已经完成或者正在等待，因为输入对象不再匹配输出对象。 在这种情况下，唯一真正理智的做法是确保前期一切都是 future。

上下文数据

除了疯狂的复杂性和对如何更好地编写 API 缺乏理解，我最大的问题是完全缺乏对上下文本地数据的考虑。这是 Node 社区现在学习的东西。continuation-local-storage 存在，但该实现被接受的太晚。持续本地存储和类似的概念常用于在并发环境中实施安全策略，并且该信息的损坏可能导致严重的安全问题。

事实上，Python 甚至没有任何存储，这令人失望至极。我正在研究这个内容，因为我正在调查如何最好地支持 Sentry's breadcrumbs 的 asyncio，然而我并没有看到一个合理的方式做到这一点。在 asyncio 中没有上下文的概念，没有办法从通用代码中找出您正在使用的事件循环，并且如果没有 monkeypatching（运行环境下的补丁），也无法获取这些信息。

Node 当前正在经历如何找到这个问题的长期解决方案的过程。这个问题不容忽视，因为它在所有生态系统中反复出现过，如 JavaScript、Python 和 .NET 环境。该问题被命名为异步上下文传播，其解决方案有许多名称。在 Go 中，需要使用上下文包，并明确地传递给所有 goroutine（不是一个完美的解决方案，但至少有一个）。.NET 具有本地调用上下文形式的最佳解决方案。它可以是线程上下文，Web 请求上下文或类似的东西，除非被抑制，否则它会自动传播。微软的解决方案是我们的黄金标准。我现在相信，微软在 15 年前已经解决了该问题。

我不知道该生态系统是否还够年轻，还可以添加逻辑调用上下文，可能现在仍然为时未晚。

个人感想

复杂的东西变得越来越复杂。 我没有随意使用 asyncio 的心智。它需要不断地更新所有 Python 语言的变化的知识，这很大程度上使语言本身变得复杂。 令人鼓舞的是，围绕着它的生态系统正在不断发展，只是不知道还需要几年的时间，才能带给开发者愉快和稳定的开发体验。

3.5 版本引入的东西（新的协程对象）非常棒。 特别是这些变化包括引入了一个合理的基础，这些都是我在早期的版本中一直期盼的。在我心中， 通过重载生成器实现协程是一个错误。 关于什么是 asyncio，我难以置喙。 这是一个非常复杂的事情，内部令人眼花缭乱。 我很难理解它工作的所有细节。你什么时候可以传递一个生成器，什么时候它必须是一个真正的协程，future 是什么，任务是什么，事件循环如何工作，这甚至还没有触碰到真正的 IO 部分。

最糟糕的是，asyncio 甚至不是特别快。 David Beazley 演示的它设计的 asyncio 的替代品是原生版本速度的两倍。 asyncio 巨复杂，很难理解，也无法兑现自己在主要特性上的承诺，对于它，我只想说我想静静。我知道，至少我对 asyncio 理解的不够透彻，没有足够的信心对人们如何用它构建代码给出建议。

作者：

Armin Ronacher

软件开发者和开源骨灰， Flask 框架的创造者。

via: http://lucumr.pocoo.org/2016/10/30/i-dont-understand-asyncio/

作者：Armin Ronacher 译者：firstadream 校对：jasminepeng

本文由 LCTT 原创编译，Linux中国 荣誉推出

基于 Red Hat 企业版的源代码的最新版本的 CentOS 7 在今年的 12月发布了 CentOS Linux 7 (1611) ，包含了许多 bug 修复、新的包更新，比如 Samba、Squid、libreoffice、SELinux、systemd 及其它软件，并支持第七代 Intel 酷睿 i3、i5、i7 处理器。

本指南会向你展示如何在 UEFI 的机器上使用 DVD ISO 镜像来安装 CentOS 7.3。

如果你要是用 RHEL，看下我们的 RHEL 7.3 安装指南。

要求

• 下载 CentOS 7.3 ISO 镜像

要在 UEFI 的机器上正确安装 CentOS 7.3，首先按下键（F2、F11 或 F12，取决与你的主板类型）进入主板的 UEFI 设置，并且确保 QuickBoot/FastBoot 以及 Secure Boot 已被禁用。

CentOS 7.3 安装

1、 在你从上面的链接下载完成镜像之后，使用 Rufus将它烧录到 DVD 或者创建一个可启动的 UEFI 兼容 USB 盘。

将 USB/DVD 放入主板上连接的驱动器中，重启电脑并用特定的功能键（F12、 F10，取决于主板类型）让 BIOS/UEFI 从 DVD/USB 启动。

ISO 镜像启动完成后，你机器上会显示如下首屏。在菜单中选择 “Install CentOS 7”并按下回车继续。

CentOS 7.3 启动菜单

2、 在安装镜像加载到内存完成后，会显示一个欢迎页面。选择你在安装中使用的语言并按下“ 继续 （ Continue ） ”按钮。

选择 CentOS 7.3 安装语言

3、 在下一个页面点击“ 日期和时间 （ Date and Time ） ”，从地图中选择你的地理位置。确认日期和时间正确配置了并点击“ 完成 （ Done ） ”按钮来回到主安装界面。

CentOS 7.3 安装总结

选择日期和时间

4、 点击“ 键盘 （ Keyboard ） ”菜单进入键盘布局页面。选择或者添加一个键盘布局并点击“ 完成 （ Done ） ”按钮继续。

选择键盘布局

5、 接下来，为你的系统添加或者配置一个语言并点击“ 完成 （ Done ） ”按钮进入下一步。

选择语言支持

6、 在这步中，你可以通过选择列表中安全配置来设置你的系统“ 安全策略 （ Security Policy ） ”。

点击选择配置按钮来选择你想要的安全配置并点击“ 应用安全策略 （ Apply security policy ） ”按钮到 On。点击“ 完成 （ Done ） ”按钮后继续安装流程。

启用 CentOS 7.3 安全策略

7、 下一步中你可以点击“ 软件选择 （ Software Selection ） ”按钮来配置你的基础机器环境。

左边的列表是你可以选择安装桌面环境（Gnome、KDE Plasma 或者创意工作站）或者安装一个服务器环境（Web 服务器、计算节点、虚拟化主机、基础设施服务器、带图形界面的服务器或者文件及打印服务器）或者执行一个最小化的安装。

为了随后能自定义你的系统，选择最小化安装并附加兼容库，点击“ 完成 （ Done ） ”按钮继续。

CentOS 7.3 软件选择

对于完整的 Gnome 或者 KDE 桌面环境，使用下面的截图作为指引。

Gnome 桌面软件选择

KDE 桌面软件选择

8、 假设你要在服务器上安装一个图形界面，选择左边那栏“ 带 GUI 的服务器 （ Server with GUI ） ”那项，并在右边那栏中根据你需要提供给客户端的服务选择合适的附加软件。

你可以选择的服务是非常多样化的，从备份、DNS 或者 e-mail 服务到文件存储服务、FTP、HA 或者监控工具。只选择对你网络设置最重要的服务。

选择带 GUI 的服务器

9、 如果你不使用特定的网络协议比如 HTTP、HTTPS、FTP 或者 NFS 的额外仓库，安装源保持默认，并点击“ 安装位置 （ Installation Destination ） ”来创建一个磁盘分区。

在“ 设备选择 （ Device selection ） ”页面，确保你已经选择了本地磁盘。同样，在“ 其他存储选项 （ Other Storage Options ） ”中确保选择了“ 自动配置分区 （ Automatically configure partitioning ） ”。

这个选项可以确保你的磁盘会恰当地根据磁盘空间和 Linux 文件系统层次结构进行分区。它会为你自动创建 /（root）、/home和 swap 分区。点击“ 完成 （ Done ） ”来应用磁盘分区方案并回到主安装界面。

重要提醒：如果你想要创建自定义分区及自定义分区大小，你可以选择“ 我要配置分区 （ I will configure partitioning ） ”选项来创建自定义分区。

安装 CentOS 7.3 安装位置

10、 接下来，如果你想要释放系统内存，点击 KDUMP 选项并禁用它。点击“ 完成 （ Done ） ”并回到主安装界面。

Kdump 选择

11、 在下一步中设置你的主机名并启用网络服务。点击“ 网络和主机名 （ Network & Hostname ） ”，在主机名中输入你的 FQDN（完整限定网域名称），如果你在局域网中有一个 DHCP 服务器，将以太网按钮从 OFF 切换到 ON 来激活网络接口。

设置网络及主机名

12、 为了静态配置你的网络接口，点击“ 配置 （ Configure ） ”按钮，手动如截图所示添加 IP 设置，并点击“ 保存 （ Save ） ”按钮来应用更改。完成后，点击“ 完成 （ Done ） ”按钮来回到主安装菜单。

配置网络和 IP 地址

13、 最后检查下所有到目前为止的配置，如果一切没问题，点击“ 开始安装 （ Begin Installation ） ”按钮开始安装。

开始 CentOS 7.3 安装向导

14、 开始安装后，一个新的设置用户界面会显示出来。首先点击 “ root 密码 （ ROOT PASSWORD ） ”并添加一个强密码。

root 账户是每个 Linux 系统的最高管理账户密码，它拥有所有的权限。设置完成后点击完成按回到用户设置界面。

选择 root 密码

设置 root 密码

15、 用 root 账户运行系统是非常不安全和危险的，因此建议你点击“ 创建用户 （ User Creation ） ”按钮创建一个新的系统账户来执行每日的系统任务。

添加新的用户，并同时选择下面的两个选项来授予用户 root 权限以及每次在登录系统时手动输入密码。

当你完成最后一项点击“ 完成 （ Done ） ”按钮并等待安装完成。

创建用户账户

16、 几分钟后安装程序会报告 CentOS 已经成功安装在你机器中。要使用系统，你只需要移除安装媒介并重启机器。

CentOS 7.3 安装完成

17、 重启之后，使用安装中创建的用户登录系统，并且用 root 权限执行下面的命令来执行系统更新。

$ sudo yum update

更新 CentOS 7.3

所有 yum 管理器的问题都选择yes，最后再次重启电脑（使用 sudo init 6）来应用新的内核升级。

$ sudo init 6

就是这样！在你的机器中享受最新的 CentOS 7.3 吧。

作者简介:

Matei Cezar

我是一个电脑上瘾的家伙，一个开源和 Linux 系统软件的粉丝，有大约 4 年的 Linux 桌面、服务器和 bash 脚本的经验。

via: http://www.tecmint.com/centos-7-3-installation-guide/

作者：Matei Cezar 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

我们开启了 Shell 脚本调试系列文章，先是解释了不同的调试选项，下面介绍如何启用 Shell 调试模式。

写完脚本后，建议在运行脚本之前先检查脚本中的语法，而不是查看它们的输出以确认它们是否正常工作。

在本系列的这一部分，我们将了解如何使用语法检查调试模式。记住我们之前在本系列的第一部分中解释了不同的调试选项，在这里，我们将使用它们来执行脚本调试。

启用 verbose 调试模式

在进入本指导的重点之前，让我们简要地探索下 verbose 模式。它可以用 -v 调试选项来启用，它会告诉 shell 在读取时显示每行。

要展示这个如何工作，下面是一个示例脚本来批量将 PNG 图片转换成 JPG 格式。

将下面内容输入（或者复制粘贴）到一个文件中。

#!/bin/bash
#convert
for image in *.png; do
convert  "$image"  "${image%.png}.jpg"
echo "image $image converted to ${image%.png}.jpg"
done
exit 0

接着保存文件，并用下面的命令使脚本可执行：

$ chmod +x script.sh

我们可以执行脚本并显示它被 Shell 读取到的每一行：

$ bash -v script.sh

显示shell脚本中的所有行

在 Shell 脚本中启用语法检查调试模式

回到我们主题的重点，-n 激活语法检查模式。它会让 shell 读取所有的命令，但是不会执行它们，它（shell）只会检查语法。

一旦 shell 脚本中发现有错误，shell 会在终端中输出错误，不然就不会显示任何东西。

激活语法检查的命令如下：

$ bash -n script.sh

因为脚本中的语法是正确的，上面的命令不会显示任何东西。所以，让我们尝试删除结束 for 循环的 done 来看下是否会显示错误：

下面是修改过的含有 bug 的批量将 png 图片转换成 jpg 格式的脚本。

#!/bin/bash
#script with a bug
#convert
for image in *.png; do
convert  "$image"  "${image%.png}.jpg"
echo "image $image converted to ${image%.png}.jpg"
exit 0

保存文件，接着运行该脚本并执行语法检查：

$ bash -n script.sh

检查 shell 脚本语法

从上面的输出中，我们看到我们的脚本中有一个错误，for 循环缺少了一个结束的 done 关键字。shell 脚本从头到尾检查文件，一旦没有找到它（done），shell 会打印出一个语法错误：

script.sh: line 11: syntax error: unexpected end of file

我们可以同时结合 verbose 模式和语法检查模式：

$ bash -vn script.sh

在脚本中同时启用 verbose 检查和语法检查

另外，我们可以通过修改脚本的首行来启用脚本检查，如下面的例子：

#!/bin/bash -n
#altering the first line of a script to enable syntax checking
#convert
for image in *.png; do
convert  "$image"  "${image%.png}.jpg"
echo "image $image converted to ${image%.png}.jpg"
exit 0

如上所示，保存文件并在运行中检查语法：

$ ./script.sh
script.sh: line 12: syntax error: unexpected end of file

此外，我们可以用内置的 set 命令来在脚本中启用调试模式。

下面的例子中，我们只检查脚本中的 for 循环语法。

#!/bin/bash
#using set shell built-in command to enable debugging
#convert
#enable debugging
set -n
for image in *.png; do
convert  "$image"  "${image%.png}.jpg"
echo "image $image converted to ${image%.png}.jpg"
#disable debugging
set +n
exit 0

再一次保存并执行脚本：

$ ./script.sh 

总的来说，我们应该保证在执行 Shell 脚本之前先检查脚本语法以捕捉错误。

请在下面的反馈栏中，给我们发送关于这篇指导的任何问题或反馈。在这个系列的第三部分中，我们会解释并使用 shell 追踪调试模式。

作者简介：

Aaron Kili 是一个 Linux 及 F.O.S.S 热衷者，即将是 Linux 系统管理员、web 开发者，目前是 TecMint 的内容创作者，他喜欢用电脑工作，并热心分享知识。

via: http://www.tecmint.com/check-syntax-in-shell-script/

作者：Aaron Kili 译者：geekpi 校对：jasminepeng

本文由 LCTT 原创编译，Linux中国 荣誉推出