configfile (md)4+8不能立刻返回主菜单

chenall

原来始此,那就不用试了,,老实说我从来没有用过GFXMENU.

zxw

将楼主的菜单简化了一下：

timeout 3
default 0
gfxmenu /message

title test1
configfile (md)4+8
commandline

title test2
configfile /menu.usr
commandline

这个菜单的两个菜单项均进入命令行。按不点的说法，因为configfile 有延迟。
但将gfxmenu语句删除，却没有进入命令行。此时说明configfile 却没有延迟。

综上，有gfxmenu时，configfile 才有延迟现象。

[ 本帖最后由 zxw 于 2011-10-1 14:31 编辑 ]

不点

你搞错了，只有当 configfile 位于 “初始化命令组” 之中的时候，它才有延迟执行的效果。延迟到其他初始化命令都执行完了之后再执行。

位于 title 之后的 configfile 命令，就和普通的 configfile 命令一样了，没有 “延迟执行” 的效果。

你的 configfile 命令 拼写错误。

幸运的草

经测试：以下菜单为GRLDR内置菜单。
timeout 3
default 0
gfxmenu /message

title test1
configfile /ss.lst

title test2
pause --wait=5 && configfile /ss.lst
commandline
而外置ss.lst中的内容
gfxmenu /message
pause --wait=5 && configfile /menu.usr
commandline

执行TEST1调用外置菜单SS。外置菜单中的语句不会出现延迟现象，5秒钟后返回主菜单。
执行TEST2即执行内置菜单，则出现延迟，5秒钟后进入命令行。
如果把主菜单中的gfxmenu /message这一句屏蔽，则一切正常。

结果：内、外菜单同一语句有别，且内与gfxmenu有关，外则无此问题。结果表明在TITLE后也是这种现象，与你的解释不符。
本想把测试标本上传，但传不上来。9月18日的GRLDR.在QEMU中测试。

[ 本帖最后由 幸运的草 于 2011-10-1 14:33 编辑 ]

zxw

实际测试并没有写错。

timeout 3
default 0
if not exist /message find --set-root /message
gfxmenu /message

title 1. test1
configfile (md)4+8
commandline

title 2. test2
if not exist /menu.usr find --set-root /menu.usr
configfile /menu.usr
commandline

其中menu.usr菜单外置。
这个菜单的两个菜单项均进入命令行。此时再按ESC键却进入了configfile的菜单。
但将gfxmenu语句删除，却没有进入命令行。

综上，有gfxmenu时，title中的configfile 有延迟现象？

[ 本帖最后由 zxw 于 2011-10-1 15:08 编辑 ]

不点

实际上可能也正是你说的这种情况。内置菜单有延迟，外置没有延迟。

主要是防止由菜单的胡乱 configfile 而导致的无限循环的发生。

外置菜单似乎不容易引起无限循环，因此，可能正常对待了。

而内置菜单不是开玩笑的，它很关键。所以，对内置菜单采取了保护措施，延迟了 configfile 的执行。

其中是否存在 bug，我也不敢肯定。

（顺便说，在你的 ss.lst 中，gfxmenu 语句似乎应该放在初始化命令组的末尾。）

另外，我发现 configfile 命令也被 chenall 更改过，不知是否有影响。

你也没有贴出 /menu.usr 的内容。

不点

我倒是怀疑，gfxmenu 命令究竟能否与 configfile 共存？

换句话说，在 gfxmenu 的情况下，是否兼容 configfile 命令？

如果这是个 bug，请确定何年何月何日引入了此 bug？

－－－－－－－－

注意：在 gfxmenu 下，它不是一个正常的 grub4dos 环境。

gfxmenu 与 grub4dos 是 “两张皮”，因此，并非 grub4dos 的命令都能在 gfxmenu 下正常工作。

举例来说，password 之类好像就不行。

[ 本帖最后由 不点 于 2011-10-1 15:10 编辑 ]

zxw

在#35号的帖子又补充了一句。
这个菜单的两个菜单项均进入命令行。此时再按ESC键却进入了configfile的菜单。
即

1. title test1
   
2. configfile (md)4+8
   
3. commandline
   

复制代码

按ESC键后回到了内置菜单。

1. title test2
   
2. configfile /menu.usr
   
3. commandline

复制代码

按ESC键后这个菜单项进入了menu.usr菜单。

zxw

在测试批处理的某个时候，configfile 命令确实被 chenall 更改过。

gfxmenu毕竟是强行改造给予grub4dos 的一个功能，很多问题都与gfxmenu有关。gfxmenu不用也罢。

[ 本帖最后由 zxw 于 2011-10-1 15:30 编辑 ]

不点

参见 37 楼后一段的说明。怀疑 gfxmenu 之下无法正常使用 configfile 命令。请全面测试，看看 0.4.4 的版本是否也存在类似问题。

幸运的草

和ZXW进行了一番讨论，原SS.LST中的内容受gfxmenu命令的影响，执行无延迟，但这个测试好像不严格。
又把原来内置菜单中的内容完全放入外置SS.LST中，发现同内置菜单一样，出出现有延迟。
menu.usr是为测试而写的一个虚拟的文件名，实际并无真实的menu.usr。
测试结论是：configfile的延迟与gfxmenu命令有关。这样的延迟可能有好处，正如不点大所说。

不点大的回复好快。

[ 本帖最后由 幸运的草 于 2011-10-1 15:29 编辑 ]

不点

不是延迟不延迟的问题，而是说，究竟 gfxmenu 与 configfile 命令能否 “兼容” 的问题。

configfile 要 “跑” 去执行另外一个 menu，而 gfxmenu 让不让它 “去” 的问题。

请测试 0.4.4，看看是否存在同样问题。

我一向对于 bug 比较看重，也比较敏感。

凡是有可能表现出 bug 的，我都会高度警惕。

zxw

测试了一下0.4.4 的版本，2009-12-03的版本。
问题同38#贴。


此时按ESC，才会回到主菜单。

[ 本帖最后由 zxw 于 2011-10-1 15:47 编辑 ]

不点

如果可能的话，也测试一下 2009-03-31 的版本。

如果都是一样的，那说明，这是老问题了。

剩下的就要看，我们究竟有没有可能去解决它了。

我现在就准备去研究一下相关的源代码。

zxw

2009-03-31 的版本无处下载了。

chenall

早期的版本这里还可以下..

http://download.gna.org/grub4dos/

zxw

测试了一下2009-03-29版本，也是一样的问题。

不点

新的测试版本刚刚上载到时空论坛，请测试。

将 configfile 和 gfxmenu 的优先级进行了调整。

当两者同时存在时，configfile 优先执行。

由于改动较大，属于 “部分不兼容” 改动，因此，请全面测试，确认没问题之后再采用。

zxw

gfxmenu有个特性，gfxmenu执行成功后，后面的语句不会执行。当菜单执行出错或按ESC退出gfxmenu后才会执行。

为防止出错后菜单乱码，目前坛内很多菜单，出现这样类似的语句：
gfxmenu /message
configfile (md)4+8
===========================
测试版将 configfile 和 gfxmenu 的优先级进行了调整，这个特性在这种菜单就“消失”了。测试版如再这样使用，呵，当然就形成无限循环了。
其它，包括本帖讨论的问题等暂时测试正常。

[ 本帖最后由 zxw 于 2011-10-1 17:30 编辑 ]

shan

仔细地看完了不点大大的分析，透亮了许多。

不点

>>> gfxmenu有个特性，gfxmenu执行成功后，后面的语句不会执行。当菜单执行出错或按ESC退出gfxmenu后才会执行。

这是没办法的事情。本来就是 “两张皮”。

>>> 为防止出错后菜单乱码，目前坛内很多菜单，出现这样类似的语句：
>>> gfxmenu /message
>>> configfile (md)4+8

现在的新版本，不可以这样用了，因为 configfile 将优先于 gfxmenu 的执行。

更新：

最新的版本（17点30分以后的编译）保持兼容性，以往的菜单无须改变。

[ 本帖最后由 不点 于 2011-10-1 18:22 编辑 ]

不点

在下午 17 点 30 分以后，又编译了一个版本。

这个版本不调整优先级，只解决冲突。这样可以保持兼容性。

试试看，估计这次没问题了。

zxw

呵，动作真快。包括0PE及一些批处理测试正常。

[ 本帖最后由 zxw 于 2011-10-1 17:54 编辑 ]

不点

大家最好尽快测试，都来报告使用情况，好让 chenall 能够决定更新到 svn 上。

幸运的草

测试正常，既不死循环也不冲突。

[ 本帖最后由 幸运的草 于 2011-10-1 18:12 编辑 ]

zxw

借此帖向不点大建议：
1.configfile (rd)+1不要改变启动设备。chenall已将configfile (md)*+*这样处置了。
2.增强目录是否存在的检测功能。
  目前，检测目录是否存在的方法大致有二：
（1）ls /test/                     缺点：目录下的文件太多时，一是影响显示，当然可以clear，但觉得有点不爽。
（2）cat --length=0 /test    缺点：分区为ntfs格式时就失灵了。
  故建议：给ls 增加一个参数，不显示目录下的文件。目录存在就返回真，否则返回假。

不点

这些就让 chenall 做吧，我都不太熟悉。chenall 一直就在做这方面的工作。

hotdll

今天送我妈回家，本来说好上传代码的。想不到不点大大已经都解决了。并发布了新版本。

对我今天没兑现承诺表示歉意。

同时为不点的高效率喝彩。我就不上传我那不堪入目的代码了。

不点

那其实是你们几位解决的。你们的劳动量比我还大。我由于身体差，只不过动动嘴皮子 “瞎指挥” 一通罢了。

无论如何，解决了就是好事。当然感谢你这个 “始作俑者” 了。没有你是不行的。

hotdll

原帖由 不点 于 2011-10-1 21:20 发表
那其实是你们几位解决的。你们的劳动量比我还大。我由于身体差，只不过动动嘴皮子 “瞎指挥” 一通罢了。

无论如何，解决了就是好事。当然感谢你这个 “始作俑者” 了。没有你是不行的。

不点大大，读懂 GRUB4DOS 的源代码需要哪些知识？我打算为grub4dos做点贡献。就当做是业余爱好。