grldr内置菜单的疑问

不点

一楼的图片显示，机器是从 CD-ROM 启动，CD-ROM 里面的 GRLDR 可能是含有内置菜单的，屏幕显示内置菜单首先获得控制，然后内置菜单又调用外置菜单，于是外置的菜单又获得控制。

这个图片已经很清楚了，你的内置菜单首先获得控制，内置菜单里面的 configfile 命令又将控制传递给 /menu.lst 这个外置菜单。

另外，你应该用新版测试，你所用的 2013 年的版本，有点旧。最好用新版试试。

不点

内置菜单中有一条不带参数的 configfile 命令，它就可以把控制传递给 /menu.lst 文件。

你可以去掉这条不带参数的 configfile 命令，这样就不会执行外置菜单了。


菜单初始化命令集里面的不带参数的 configfile 命令，其作用是把控制转移到 “默认” 的外置菜单文件。

grldr 启动后，就有一个默认的位置（即当前工作目录）。它通常是 grldr 所在设备的根目录。

这个默认位置上的 menu.lst 文件，就是默认的外置菜单文件。

不点

那是智能判断的结果。为了防止无限多次执行 /menu.lst 导致循环死机，程序对此作了处理，只有第一次执行不带参数的 configfile 命令时才会执行默认的外置菜单，以后如果再次执行这条不带参数的 configfile 命令，那就失效了，当成空操作，什么也不做，直接执行 configfile 之后的命令。这是防止反复执行这条无参数的 configfile 命令导致无限循环死机的发生。

不点

默认的外置菜单，不一定是 /menu.lst，因为用户可以修改它的位置以及文件名。它位于 grldr 的第二扇区。也就是说，/menu.lst 不等价于默认的外置菜单。

另外，即使像楼上 fukystone 所说的那样，写成 configfile /menu.lst，这对于用户的错误使用所导致的无限循环死机，也是无能为力，情况完全一样，丝毫没有改观。即：用户在外置菜单中执行内置菜单，而内置菜单又立即要执行外置菜单，这样必然是无限循环。

权衡一下，能够容错，防止用户产生死机，应该是更贴心的。因为这是能够做到的，我们就可以去做；如果我们做不到，那就到处广告，提醒用户不要犯某某错误，正如我们到处广告，不要错误地执行 find --set-root 那样。多费劲啊。

其实，世上没有完美的东西，鱼与熊掌不可兼得。任何一个做法，都有其优缺点。权衡的时候，只能采取其一，而不能兼顾所有的情况。


grub4dos 里面，没用的东西有很多，如果要精简的话，还轮不到考虑清理掉 configfile 这点逻辑设计。另外，已经实现的功能，不是说想去掉就去掉了，随随便便。你不需要的东西，别人可能在用。去掉了某个东西，可能会给别人带来麻烦。你觉得某个东西不好，你可以不用它，甚至你可以编译自己的版本，彻底去掉它；这是可以的。但是，如果要影响到别人的使用、影响到兼容性，那就是一个慎重的话题了。

不点

sratlf 发表于 2014-6-10 12:37
好吧  如果能加个提示就好了  要不然有的用户会把第二次无法加载当成问题看待。。。

具体怎么加提示信息，你可以给个方案。我一点都不反对加提示信息，但我知道，我们的用户以及第三方开发者、发行者、以及最终使用者当中，有很多人反对增加提示信息。

如果你是指写到文档里面，那就不是 chenall 等开发维护者的责任了，因为那是你的责任，大家都在依靠你写的文档材料。当然，这些文档，广义来看，也属于开发的一部分。

不点

不准确。执行一次的不是 /menu.lst，而是 不带参数的 configfile 命令。

执行任何一个 menu.lst 文件之前（不管它位于何处，也不管它叫什么名字），都会显示 Processing menu file ..... 的信息，而且它并不被限定只执行一次，而是可以执行任意多次，只要你用 configfile /menu.lst 就总是可以执行。

不点

长没关系，电脑打印的速度还是很快的。

问题是，这对用户不一定有多少帮助。用户通常不会留意这条信息，而且中文用户更不容易留意这条信息。

一闪而过的信息，即使你想看，都来不及。如果故意暂停几秒，拖延机器启动速度，不划算，我估计有人要抱怨了。

有鉴于只有高级用户（有一定的开发能力的用户）才关心这些东西，因此我觉得，只要在文档中加以公布，就可以了。高级用户通常都会仔细研读文档的。


另外，我认为，内置菜单中的无参数 configfile 命令，第一次把控制权交给外部的默认菜单以后，本来就不应该有第二次了。这是因为，当用户执行内置菜单的时候，用户希望内置菜单真正开始执行，而不是自动又一次地跳到外置的菜单里面，形成死循环。这个设计本来就没有毛病。因此，在文档中加以公布，是很自然的，很容易得到大家的理解。

如果某些应用场景需要多次执行 configfile，那么，菜单的设计者可以把内置菜单中的这条不带参数的 configfile 命令改成带参数的 configfile /menu.lst 命令，这就会反复执行了（当然也可能会造成无限循环死机）。注意，这条 configfile /menu.lst 命令之后的那些命令，都没有机会能够获得执行。configfile /menu.lst 就相当于无条件 goto 到 /menu.lst 里面去了，而且不能返回到内置菜单中，即，不能继续执行内置菜单里面其余的命令了。

当硬盘某个隐蔽的分区的根目录下存在某个 menu.lst 文件，并且这个文件的开头有一条语句是执行内置菜单的时候，那就很容易造成无限循环死机，而且这种死机是难以排查的。不明真相的用户可能会认为是 grub4dos 的 bug 造成的，甚至认为 grub4dos 的开发者是垃圾，从而抛弃 grub4dos。

具体应该怎么做，那就看各位开发者、应用者自己的决定了。没有两全其美的方案，只有折中的方案。

不点

用户用到某个功能，就应该查文档，查用法说明。任何命令，都应该有说明。没有说明的命令，那就没法用。关键是应该完善说明书。

前面已经说了，如果 configfile 命令总是无条件转向 /menu.lst，那么后续的命令全都没有机会得到执行。这显然是不合乎逻辑的。因此，限制 configfile 命令只能执行一次，是很自然的，稍动脑筋就会理解的。