很久以前，当我第一次读到“程序员修炼(The Pragmatic Programmer)”时，我读了一些让我真真难以忘怀的建议。

“不要使用手工流程(Don’t Use Manual Procedures)”。

这在Ubiquitous Automation一节。总之，他们希望你将所有的事情都自动化。

麻烦的是，我对于如何真正的让任何东东都自动化并没有太多的想法。当时，我仍困于这样一个世界，其中所有的程序都是一个使用CLI的庞大的Java程序，而我的印象是，命令行界面无非是过去时代的一个垂死残余。

我的一些假装自动化之旅充满了陷阱和自我无能的尴尬故事，而我希望与大家分享这些故事。

bash脚本编程

与命令行系统交互的陷阱之一是，每一个复杂的交互使用一个同样复杂的命令 —— 而对于那些我可能会一次又一次运行的命令，每次我都将不得不记得精确的调用。

大多数时候，这个可以工作，虽然每次都要花不少的时间上谷歌或StackOverflow搜索。

关于幻想小说的一个持久的事情是，你总能看到追随者使用魔杖，但没有魔法书。这是因为他们都是愚蠢的。奇才携带魔法书。

所以，我开始写下我的命令，这样我就不会忘记它们。而不是将这些命令写到便利贴，或笔记本上，我将它们写到我的home目录下。

起初，我只想cat这个文件，然后将该命令复制回命令行。

我和你说了，我会分享我尴尬无能的故事。

我很快意识到，没有真的有打算，我写的是bash脚本 – 我只是没有明智地执行它们。如果我只是告诉系统我要像执行程序一样执行这个文件，那么它应该足够明智地工作。

Hashbang

仅凭这一点是不够好到让这个脚本正常工作的，但我们没有做很多的事来帮助系统弄清楚到底如何运行这个我们传给它的神秘的脚本。

让我们想象下我们创建了一个文件：

这在Python 3中是有效的，但在Python 2中无效。如果我们将这个文件保存为’hello’，那么我们基本不知道怎样运行它。而如果我们尝试运行，计算机将会进行猜测，然后它会猜错。

如果我们将文件命名为hello.py，给我们自己一个方便的线索以便提示自己这个是个怎么样的文件，那么我们可以使用Python解释器来执行它。

好吧，它工作了，但对于程序调用来说压力山大。七十年代的一个Unix创新可以消除这个问题：hashbang。在我们脚本的开头，我们可以准确的声明想使用哪个解释器。

这里唯一的规则是，编译器必须存在于系统的$PATH变量中。当你在本地运行该脚本时，是挺棒的，但如果你远程运行脚本而不使用一个伪终端会话集时，你或许并没有一个$PATH变量，这将导致你的hashbang声明失败。

解决方法？hashbang可以包含你打算用于程序的解释器的完整路径。

在很多现代编程中，你没有看到这个令人兴奋的技术，因为它并不是引人注目的可便携的 —— 你用来执行一个python程序的解释器的位置，甚至是名字，往往系统与系统之间并不相同。

虽然，bash通常位于/bin/bash，这就是为嘛sun下的每个bash程序都用#!/bin/bash打开。

Bashy Bash

所以，不久以后，我的home目录到处都开始充斥着名字诸如work.sh和test.sh这样的有用的小的bash文件。

Alias

如果你在Django中编程，你可能还记得，你可以在Django环境中调用的每个命令都是通过直接引用程序manage.py开始的。

我也许像这样启动Django开发服务器：