[syslinux] Issues with syslinux_run_command(str) and parameters

[Ady]

> I didn't see any further communication here; would anyone be
> against my submitting/proposing a patch for this? 

Contributions are always welcome.

> 
> I can see two possible approaches. One approach would be to
> isolate the restriction on user commands away from
> syslinux_run_command / load_kernel. 
> 
> Another would perhaps be to add support for a 'NOTAB' or
> 'NOTABTOEDIT' option. There already exists a NOESCAPE setting, so
> the remaining piece would be restricting tab. (And perhaps holding
> shift to get to the console.. Hmm.) 
> 
> I would appreciate any suggestions :)
> 
> Thank you,--Ian 
> 
 
>From the perspective of a final user, breaking the prior behavior of 
directives needs to have very clear advantages.

The NOESCAPE (related to [esc]) and ALLOWOPTIONS (related to [tab]) 
directives have clear (and independent from each other) behaviors. 
Instead of changing their behaviors, the alternatives would be:
_ to find available workarounds (which was already proposed); or,
_ to add new directives.

IIRC, there are no "Global Directives" that apply to specific types 
of kernels or images but not to others (e.g. to modules but not to 
Linux), specially when they have no additional parameter. Introducing 
such type of additional classification could perhaps lead to more 
troubles than it's worth.

Considering that there is already a workaround available, I wonder if 
the inconvenience of having to add "too many" LABEL entries could be 
defeated by reorganizing your Syslinux configuration files.

For instance, using an initial cfg file with the "automatic" entries 
(those that don't require user interaction, such as whichsys.c32, 
ifcpu.c32...) and only then actually showing a [vesa]menu with the UI 
directive (in a second, in-common, cfg file). The individual 
configuration files can be then connected using directives such as 
INCLUDE and CONFIG (typical examples with multiple configuration 
files are available in ArchLinux and Debian, among others).

Regards,
Ady.