神話の個人的なブログの著者：からの神話がリンクします。https：//blog.mythsman.com/2017/07/23/1/（元のテキストが最後尾に行く読むためにクリックしてください）
序文
必要性に、最近整頓シェルスクリプトを再開しました。彼らの通常のコマンドの大部分はしばしば使用されるが、書かれたとき必ず書かれたスクリプトは醜いと感じられているが。私は他の人によって書かれたスクリプトを見たときに、常にそれが困難読むことを見つけます。結局、このことは、まともなシェルスクリプトプログラミング言語ではありません、彼はより多くの私たちの呼び出しのための雑種の異なるプログラムのためのツールのようなものです。また、非常に多くの書き込み時の人々が、基本的には、いくつかの長いメイン関数のように書き込む場所に、見て耐えることができなかったところを考えます。同時に、歴史的な理由によるものに、シェルの多くの異なるバージョンがありますが、多くのコマンドがあり、我々は、統一することは困難である標準コードオフをトレードする必要が同じ機能を持っています。
上記のこれらの理由から、私はいくつかの関連文書を見上げ、実際にはこれらの問題を見つけ、多くの人々はそれについて考えたが、また良い記事の数が、散乱まだ少しを形成しています。だから私は、私は技術仕様の後にスクリプトを書いたように、これらの記事を少しソートするためにここにいます。
コードスタイルガイド
「ヘビスティック」の開始時に
いわゆるシェバングが実際にスクリプトの多くの最初の行は、コメントの開始時に「＃！」と表示されている、彼はデフォルトのインタプリタインタプリタ、一般的には次のようになりますときに我々が指定されていませんでしたときに指摘しました：
もちろん、bashのに加えて、我々は次のコマンドでインタープリタのネイティブサポートを参照することができ、多くの通訳があります。
我々は、それは$ SHELLインタプリタによって指定されたデフォルトうシェバングない場合は、スクリプトを実行するために、直接./a.sh使用する場合、それ以外の場合は、指定されたシェバングインタプリタを使用します。
しかし、このようなアプローチは、上記の適応を持っていない可能性があり、我々は一般的に次のように指定されます。
このアプローチは、推奨される使用法です。
コード注釈付き
メモは、明らかに常識であるが、ここで再び、これはシェルスクリプトで特に重要であることを強調しています。1行のシェルコマンドの多くは、何のコメントを理解しないことは簡単ではないので、それは特に大型ヘッドのメンテナンスでは、人々を行います。
コメントの目的を説明するだけでなく、意味、それはREADMEのように、私たちに注意を伝えます。
具体的には、シェルスクリプトのために、ノートには、一般的に次のセクションが含まれます。
シェバング
スクリプトのパラメータ
脚本的用途
脚本的注意事项
脚本的写作时间，作者，版权等
各个函数前的说明注释
一些较复杂的单行命令注释
参数要规范
这一点很重要，当我们的脚本需要接受参数的时候，我们一定要先判断参数是否合乎规范，并给出合适的回显，方便使用者了解参数的使用。
最少，最少，我们至少得判断下参数的个数吧：
变量和魔数
一般情况下我们会将一些重要的环境变量定义在开头，确保这些变量的存在。
这种定义方式有一个很常见的用途，最典型的应用就是，当我们本地安装了很多java版本时，我们可能需要指定一个java来用。那么这时我们就会在脚本开头重新定义JAVA_HOME以及PATH变量来进行控制。
同时，一段好的代码通常是不会有很多硬编码在代码里的“魔数”的。如果一定要有，通常是用一个变量的形式定义在开头，然后调用的时候直接调用这个变量，这样方便日后的修改。
缩进有规矩
对于shell脚本，缩进是个大问题。因为很多需要缩进的地方(比如if,for语句)都不长，所有很多人都懒得去缩进，而且很多人不习惯用函数，导致缩进功能被弱化。
其实正确的缩进是很重要的，尤其是在写函数的时候，否则我们在阅读的时候很容易把函数体跟直接执行的命令搞混。
常见的缩进方法主要有”soft tab”和”hard tab”两种。
所谓soft tab就是使用n个空格进行缩进(n通常是2或4)
所谓hard tab当然就是指真实的””字符
这里不去撕哪种方式最好，只能说各有各的优劣。反正我习惯用hard tab。
对于if和for语句之类的，我们最好不要把then，do这些关键字单独写一行，这样看上去比较丑。。。
命名有标准
所谓命名规范，基本包含下面这几点：
文件名规范，以.sh结尾，方便识别
变量名字要有含义，不要拼错
统一命名风格，写shell一般用小写字母加下划线
编码要统一
在写脚本的时候尽量使用UTF-8编码，能够支持中文等一些奇奇怪怪的字符。不过虽然能写中文，但是在写注释以及打log的时候还是尽量英文，毕竟很多机器还是没有直接支持中文的，打出来可能会有乱码。
这里还尤其需要注意一点，就是当我们是在windows下用utf-8编码来写shell脚本的时候，一定要注意这个utf-8是否是有BOM的。默认情况下windows判断utf-8格式是通过在文件开头加上三个EF BB BF字节来判断的，但是在Linux中默认是无BOM的。因此如果我们是在windows下写脚本的时候，一定要注意将编码改成Utf-8无BOM，一般用notepad++之类的编辑器都能改。否则，在Linux下运行的时候就会识别到开头的三个字符，从而报一些无法识别命令的错。
权限记得加
这一点虽然很小，但是我个人却经常忘记，不加执行权限会导致无法直接执行，有点讨厌。。。
日志和回显
日志的重要性不必多说，能够方便我们回头纠错，在大型的项目里是非常重要的。
如果这个脚本是供用户直接在命令行使用的，那么我们最好还要能够在执行时实时回显执行过程，方便用户掌控。
有时候为了提高用户体验，我们会在回显中添加一些特效，比如颜色啊，闪烁啊之类的，具体可以参考ANSI/VT100 Control sequences这篇文章的介绍。
密码要移除
不要把密码硬编码在脚本里，不要把密码硬编码在脚本里，不要把密码硬编码在脚本里。
重要的事情说三遍，尤其是当脚本托管在类似Github这类平台中时。。。
太长要分行
在调用某些程序的时候，参数可能会很长，这时候为了保证较好的阅读体验，我们可以用反斜杠来分行：
注意在反斜杠前有个空格。
编码细节规范
代码有效率
在使用命令的时候要了解命令的具体做法，尤其当数据处理量大的时候，要时刻考虑该命令是否会影响效率。
比如下面的两个sed命令：
他们的作用一样，都是获取文件的第一行。但是第一条命令会读取整个文件，而第二条命令只读取第一行。当文件很大的时候，仅仅是这样一条命令不一样就会造成巨大的效率差异。
当然，这里只是为了举一个例子，这个例子真正正确的用法应该是使用head -n1 file命令。。。
勤用双引号
几乎所有的大佬都推荐在使用”$”来获取变量的时候最好加上双引号。
不加上双引号在很多情况下都会造成很大的麻烦，为什么呢？举一个例子：
他的运行结果如下：
为啥会这样呢？其实可以解释为他执行了下面的命令：
在很多情况下，在将变量作为参数的时候，一定要注意上面这一点，仔细体会其中的差异。上面只是一个非常小的例子，实际应用的时候由于这个细节导致的问题实在是太多了。。。
巧用main函数
我们知道，像java，C这样的编译型语言都会有一个函数入口，这种结构使得代码可读性很强，我们知道哪些直接执行，那些是函数。但是脚本不一样，脚本属于解释性语言，从第一行直接执行到最后一行，如果在这当中命令与函数糅杂在一起，那就非常难读了。
用python的朋友都知道，一个合乎标准的python脚本大体上至少是这样的：
他用一个很巧妙的方法实现了我们习惯的main函数，使得代码可读性更强。
在shell中，我们也有类似的小技巧:
我们可以采用这种写法，同样实现类似的main函数，使得脚本的结构化程度更好。
考虑作用域
shell中默认的变量作用域都是全局的，比如下面的脚本：
他的输出结果就是2而不是1，这样显然不符合我们的编码习惯，很容易造成一些问题。
因此，相比直接使用全局变量，我们最好使用local readonly这类的命令，其次我们可以使用declare来声明变量。这些方式都比使用全局方式定义要好。
函数返回值
在使用函数的时候一定要注意，shell中函数的返回值只能是整数，估计是因为一般情况下一个函数的返回值通常表示这个函数的运行状态，所以一般都是0或者是１就够了，因此就设计成了这样。不过，如果非得想传递字符串，也可以通过下面变通的方法:
这样，通过echo或者print之类的就可以做到传一些额外参数的目的。
间接引用值
什么叫间接引用？比如下面这个场景：
我们有一个变量VAR1，又有一个变量VAR2，这个VAR2的值是VAR1的名字，那么我们现在想通过VAR2来获取VAR1的值，这时候应该怎么办呢？
比较土鳖的方法是这样：
这个用法的确可行，但是看起来十分的不舒服，很难只管的去理解，我们并不推荐。而且事实上我们本身就不推荐使用eval这个命令。
比较舒服的写法是下面这样:
通过在变量名前加一个!就可以做到简单的间接引用了。
不过需要注意的是，用上面的方法，我们只能够做到取值，而不能做到赋值。如果想要做到赋值，还要老老实实的用eval来处理:
巧用heredocs
所谓heredocs，也可以算是一种多行输入的方法，即在”<<”后定一个标识符，接着我们可以输入多行内容，直到再次遇到标识符为止。
使用heredocs，我们可以非常方便的生成一些模板文件：
学会查路径
很多情况下，我们会先获取当前脚本的路径，然后一这个路径为基准，去找其他的路径。通常我们是直接用pwd以期获得脚本的路径。
不过其实这样是不严谨的，pwd获得的是当前shell的执行路径，而不是当前脚本的执行路径。
正确的做法应该是下面这两种：
应当先cd进当前脚本的目录然后再pwd，或者直接读取当前脚本的所在路径。
代码要简短
这里的简短不单单是指代码长度，而是只用到的命令数。原则上我们应当做到，能一条命令解决的问题绝不用两条命令解决。这不仅牵涉到代码的可读性，而且也关乎代码的执行效率。
最最经典的例子如下：
cat命令最为人不齿的用法就是这样，用的没有任何意义，明明一条命令可以解决，他非得加根管道。。。
其实代码简短在还能某种程度上能保证效率的提升，比如下面的例子：
这两种方法做的事情都一样，就是查找所有的.txt后缀的文件并做一系列替换。前者是多次执行find，后者是执行一次find，但是增加了sed的模式串。第一种可读性更好一点，但是当替换的量变大的时候，第二种的速度就会比第一种快很多。这里效率提升的原因，就是第二种只要执行一次命令，而第一种要执行多次。
并且，巧用xargs命令，我们还可以十分方便的进行并行化处理:
通过-P参数指定并行度，可以进一步加快执行效率。
命令并行化
当我们需要充分考虑执行效率时，我们可能需要在执行命令的时候考虑并行化。shell中最简单的并行化是通过”&”以及”wait”命令来做:
当然，这里并行的次数不能太多，否则机器会卡死。稍微正确的做法比较复杂，以后再讨论，如果图省事可以使用parallel命令来做。
使用新写法
这里的新写法不是指有多厉害，而是指我们可能更希望使用较新引入的一些语法，更多是偏向代码风格的，比如
尽量使用func(){}来定义函数，而不是func{}
尽量使用[[]]来代替[]
尽量使用$()将命令的结果赋给变量，而不是反引号
在复杂的场景下尽量使用printf代替echo进行回显
事实上，这些新写法很多功能都比旧的写法要强大，用的时候就知道了。
其他小tip
考虑到还有很多零碎的点，就不一一展开了，这里简单提一提。
路径尽量保持绝对路径，绝多路径不容易出错，如果非要用相对路径，最好用./修饰
优先使用bash的变量替换代替awk sed，这样更加简短
简单的if尽量使用&& ||，写成单行。比如[[ x > 2]] && echo x
当export变量时，尽量加上子脚本的namespace，保证变量不冲突
会使用trap捕获信号，并在接受到终止信号时执行一些收尾工作
使用mktemp生成临时文件或文件夹
利用/dev/null过滤不友好的输出信息
会利用命令的返回值判断命令的执行情况
使用文件前要判断文件是否存在，否则做好异常处理
不要处理ls后的数据(比如ls -l | awk '{ print $8 }')，ls的结果非常不确定，并且平台有关
读取文件时不要使用for loop而要使用while read
静态检查工具shellcheck
概述
为了从制度上保证脚本的质量，我们最简单的想法大概就是搞一个静态检查工具，通过引入工具来弥补开发者可能存在的知识盲点。
githubの上で本当に、shellcheckと呼ばれるツールを見つけるために多くを求めて、小さなオープンソースシェル静的チェックツールの市場は、以上の8Kスターはまだ非常にトリッキーに見えた、があります。私たちは、特定のインストールおよび使用方法の詳細については、彼のホームページに行くことができます。
インストール
異なるプラットフォームでは、このツールをサポートし、少なくとも彼は大きなサポートされています。
プラットフォームのDebian、アーチ、Gentooの、EPEL、Fedoraの、OS X、openSUSEのさまざまなので、主流のパッケージ管理ツールで。簡単にインストールします。インストールマニュアルを具体的に参照
統合されました
それは静的チェックツールですので、それはCIフレームワークに統合されなければならない、shellcheckは非常に簡単にトラヴィスCI、プロジェクト静的チェックのためのシェルスクリプトベースの言語に統合することができます。
サンプル
ドキュメント内の不正なコードのギャラリーでは、だけでなく、それは非常に良い参考値引退した時にブックの「Javaのpuzzlers」などとして使用され、まだ読んで非常に快適に座ることができた非常に詳細な基準「不正なコード」を提供A。
自然
しかし、私はこのプロジェクトの最も本質的な部分は、上記の機能はないと思うが、彼は非常に、非常に強力なWikiを提供します。このウィキでは、我々は判断に基づいてすべてのツールを見つけることができます。ここで、検出された問題のそれぞれは、問題に対応する数でウィキで見つけることができ、彼は「これは、書くことはできません」と「なぜ書かないで」を教え、「私達は私達が行く方法を記述しなければならないことを教えてくれるだけでなく、さらなる研究のための「非常に好奇心旺盛パーティー。
また、私たちは学習知識ベースを一緒に入れ、あなたが見ることができます：
スーパーフル仕上げ[]フル戦闘ノートを実行している「Linuxのクラウド・コンピューティング・マスタリング」シリーズ| Linuxの運用・保守の部族
www.magedu.com
私はあなたのすべてが何かを学びたい、あなたが助けを願っています。より多くの技術的な知識+ V156 5219 9186、オンライン答えああ喜び豆のために
ます。https：//blog.51cto.com/mageedu/2409943で再現