search for: syslinux_run_cmd

...ctures, PCI devices, lua scripting scenarios, etc.) By blocking modules, I meant that as long as I disable user editing of menu commands via ALLOWOPTIONS 0, I cannot use any of the following com32 modules without creating duplicate LABEL entries for each possible scenario. All of these modules use syslinux_run_cmd() so parameters on the command line will not be received: - gfxboot.c32- cmd.c32- lua.c32- ethersel.c32- ifcpu.c32- ifcpu64.c32- ifmemdsk.c32- ifplop.c32- whichsys.c32- rosh.c32 This doesn't feel like an intended restriction of ALLOWOPTIONS 0. --Ian > From: ady-sf at hotmail.com > To:...

...I devices, lua scripting scenarios, etc.) > > By blocking modules, I meant that as long as I disable user editing of menu commands via ALLOWOPTIONS 0, I cannot use any of the following com32 modules without creating duplicate LABEL entries for each possible scenario. All of these modules use syslinux_run_cmd() so parameters on the command line will not be received: > - gfxboot.c32- cmd.c32- lua.c32- ethersel.c32- ifcpu.c32- ifcpu64.c32- ifmemdsk.c32- ifplop.c32- whichsys.c32- rosh.c32 > > > This doesn't feel like an intended restriction of ALLOWOPTIONS 0. > > --Ian > > &...

I did confirm earlier that this does work, and combined with a MENU HIDDEN to hide it from the visible menu it is a possible solution. I originally assumed that this was due to that going down a different code path and did not mention it, apologies. The scale of my menu makes doubling/tripling menu entries less ideal, though. Do we consider it intended functionality that modules such as whichsys