为什么用 python 重写 shell-script

Question

这里是实际上的原文:

什么情况下你会需要用 python 重写工作脚本呢? 是否有任何商业上的原因?

我的回答可能让人厌恶。

简单来说，我认为 shell 脚本语言恐怕是有史以来最糟糕的编程语言. 好吧，我想它比 whitespace 之类的其他语言（参见: https://en.wikipedia.org/wiki/Esoteric_programming_language ) 还是要好点的。

详细来说，有下面几个理由:

• 我手头上的项目中（至少) 有三个 ksh 脚本是相互引用的，其中有两个脚本操作了 1000 行. 而且我还不是特别清楚他们之间的引用关系. 这是 ksh. 代码可能来自各种各样的地方，并具有含糊不清的路径；例如 source 命令以及它的同义词`.'命令。
• 脚本中，除了 #!/usr/bin/ksh ​ 外，没有任何注释. 而且有些地方的代码被注释掉了但是没有写明为什么要注释掉。
• 没有任何参考文档. 作者虽然有写过一封 email 来描述 github 仓库，但这个仓库本身缺少 README. 很难让他们明白在仓库添加 README 的重要性. 仓库中甚至缺少命令行说明. (最终我是通过查看命令行选项的解析器来推测出该说明的)
• 没有任何的测试。

最后一点尤其让我震惊. And I find it shocking on a regular basis.

人们能够并且愿意编写一个上千行的脚本而不带任何单元测试，集成测试, 系统测试，性能测试甚至是任意一种测试. 我不能理解他们怎么知道这个脚本到底是否能正常工作? 我该如何相信这个脚本?

更重要的是，在都不知道命令行接口的情况,我怎么可能将之包装成一个 RESTful API 呢? shell 还可能使用未说明的环境变量，且只有当他们引发程序运行崩溃后才可能发现他们. 程序崩溃会引发一个 HTTP 500 状态码的错误，并在日志中记录下错误信息。

"商务导向"尝试从商务上成本与收益的角度来讨论技术方案. 从这个角度来说，这种 1000 行的 shell 脚本代码很明显是一种技术负债。

最简单的解决方式恐怕就是使用类似的 Python 脚本来翻写原 shell 脚本了. 有时很难看懂一个 shell 函数到底是干嘛用的. 不停的使用（或重用) 全局变量使得很难追踪程序状态的变更. 另外，使用临时文件作为设置状态的一种方式也是个很严重的问题。

重要的是,shell 脚本中所用到的那些 OS 服务都是可仿真的. 这意味着这百来个函数可以单独的进行测试. 一旦完成了重写，重构也变得简单了。

让我们再回味一下这些单词: 可以 独立 测试

（我认为）最好的替代是 250 行或更少的 python 代码. 而且能实时地自动执行 8 个步骤. 摆脱 bash 语言的糟粕很有挑战性，但是却是必须的。