这里是实际上的原文:
什么情况下你会需要用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语言的糟粕很有挑战性,但是却是必须的.