StackOverflow上出现一个问题，询问如何init.d用Python 编写脚本。一条评论指出，这些脚本应该在Shell中编程，而不是Python。正在init.d用Python 编写脚本：
- 坏。坏。坏。永远不要这样做。
- 不建议这样做。
- 好的，请注意。
- 旧式教条。
- 完全可以。
知道任何噩梦场景，或者如果此规则写在某些系统管理员的血液中，那将是很好的。
StackOverflow上出现一个问题，询问如何init.d用Python 编写脚本。一条评论指出，这些脚本应该在Shell中编程，而不是Python。正在init.d用Python 编写脚本：
知道任何噩梦场景，或者如果此规则写在某些系统管理员的血液中，那将是很好的。
Answers:
我会说＃2，但非常接近＃1-“坏。坏。坏。永远不要这样做。” 例如，Linux初始化脚本的标准在LSB中，尽管它从未出现并说“这些是bourne shell脚本”，但还是有一些假设。第一，以＃开头的行是注释，碰巧可以正常工作。更有问题的是，要求初始化脚本从/lib/lsb/init-functions“在当前环境中执行命令（请参见shell特殊内置命令点）”执行。
但是更重要的是，如果您在这里做的事情真的很复杂，那么您做错了。初始化脚本应该非常简单实用。它们应该是经典意义上的脚本，而不是程序。最好吸纳它并编写一个简单的shell脚本，使任何sysadmin都可以轻松快速浏览它们，而不是用Python制作出精美的东西。
要记住的另一个考虑因素是systemd，这可能是也可能不是Linux上所有系统初始化的未来。在systemd下，初始化是通过简单的配置文件而不是脚本完成的，即所有启动都适合几种标准设计模式，实际上您只需要选择一种即可。如果您的程序使用了复杂的初始化内容，则该内容应超出init脚本本身。
如果您知道，可以肯定的是，我没有看到问题，当运行init.d脚本时，Python解释器将可用。对我来说，这表明您正在考虑在多用户（或“图形控制台”）运行级别中相对较晚地完成某项工作。
但是……这意味着特定版本的Python解释器对于启动顺序可能至关重要，这是您在升级时需要检查的其他内容。
我想这意味着我要说的是“ 3.好，请注意”。
我同意“ 3.好的，请注意”，但是出于不同的原因。我在Solaris上的经验是，他们为某些内部程序安装了Perl的OS副本。Shell脚本无非是使Perl启动的Shell。启动脚本是否必须用sh编写？否，但是它改善了管理员的可维护性。和init脚本一样，没有什么比daemon --start或复杂的了daemon --stop。如果这样做，则常规用户可以在非特权模式下启动您的工具，如果这在您的程序上下文中有意义的话。而且，他们不需要复杂的设置。
现代Linux发行版（即使仍在使用的发行版）也init.d具有大量的预建功能，旨在简化守护程序的管理。图形启动过程通常会利用这些功能来保持漂亮的徽标，除非启动脚本之一开始产生错误。您的Python代码（或任何其他语言）可能不适用于这些方案。
如果您不关心美观或可维护性，则可以根据需要编写init脚本。我见过很多管理员，他们甚至无法正确剪切和粘贴，完全忽略了命令行参数，而他们只是启动了守护程序。没有关机，状态或重新启动。这还不成熟，但是他们的代码仍然有效。