它主要是历史性的,部分是系统管理方面的控制问题,部分是可移植性问题,部分是调试问题。
“回到过去”,没有 autoconf、dpkg、rpm。您有时从 UUCP 下载了软件,编译了产品,并根据您自己的约定确定了产品的安装位置。将产品连接到启动/关闭系统被认为是系统管理员的职责。系统管理员将编写rc
脚本并将其放置在该系统的适当位置 ( /etc/inittab
, /etc/rcN.d/
, /etc/rc.local
, /etc/inetd.conf
)。由于处于前沿的非 linux 系统越来越少,这些本地选择的出现rpm
并dpkg
使得其中一些本地选择变得不那么重要。
系统管理员也喜欢对他们的系统进行某种程度的控制,最容易编写、调试和修改的是 shell 脚本,而不是 C 程序。
正如我之前提到的,不同的 UNIX 操作系统有不同的启动方式。为您自己的系统编写一个简短的 shell 脚本比开发人员为即将出现的每种可能的 UNIX 风格编写要容易得多(同样,这甚至在 autoconf 之前):SysV、Ultrix、Irix、HP-UX、SunOS、Solaris、 NextStep、NonStop 等。在大多数情况下,它们分为两三个机制,但每个机制都有自己的扭曲。
引导系统很容易变得复杂。最好有一个 shell 脚本,您可以在其中打印调试信息、更改流程、处理程序作者没有预料到的交互。如果这是一个已编译的程序,则查找此类错误将变得更加困难。
现代系统具有更新的机制,但大多数仍会调用 shell 脚本,主要是出于上述原因。
归档时间: |
|
查看次数: |
532 次 |
最近记录: |