Syslinux - May 2014 - Issues with syslinux_run_command(str) and parameters

>>
>> >From the perspective of a final user, breaking the prior behavior
of
>> directives needs to have very clear advantages.
> 
> Reviewing the commit history, I would say that the prior behavior is
currently broken.
> 
> The ALLOWOPTIONS feature was added in 2004:
>
http://git.zytor.com/?p=syslinux/syslinux.git;a=commit;h=975a4c3b343c09a340d95f1a2a4ece3556c57a10
> And syslinux_run_command() in 2007:
>
http://git.zytor.com/?p=syslinux/syslinux.git;a=commit;h=0b3b862ff49ab1b0b5d5af8c15d58e3c4baaf634
> 
> At this point, syslinux_run_command is using the equivalent of
> create_args_and_load(), a function that is *not* negatively affected
> by ALLOWOPTIONS.
> 
> The behavior was changed in 2013 to use load_kernel to *add* label support:
>
http://git.zytor.com/?p=syslinux/syslinux.git;a=commit;h=04f40bc55ed4f39d6c625b017bb16907f7d50c05
> 
> At this point the 8 or 9 com32 modules I listed earlier stopped working
> when ALLOWOPTIONS was set. This is a change from the previous 6 years
> of behavior.
> 
> But, if we still have different views on this, it looks like ALLOWOPTIONS
> is internally referred to as 'allowedit' in the menu code. Perhaps
> we can separate them there, maintaining an ALLOWOPTIONS' variable for
> load_kernel to check, but also adding a ALLOWEDIT option that the menu
> can use to restrict the Tab to edit functionality.
> 
> Thoughts?
> 
I do agree that the current behavior is most likely an inadvertent
regression.

	-hpa

> >>
> >> >From the perspective of a final user, breaking the prior
behavior of
> >> directives needs to have very clear advantages.
> > 
> > Reviewing the commit history, I would say that the prior behavior is
currently broken.
> > 
> > The ALLOWOPTIONS feature was added in 2004:
> >
http://git.zytor.com/?p=syslinux/syslinux.git;a=commit;h=975a4c3b343c09a340d95f1a2a4ece3556c57a10
> > And syslinux_run_command() in 2007:
> >
http://git.zytor.com/?p=syslinux/syslinux.git;a=commit;h=0b3b862ff49ab1b0b5d5af8c15d58e3c4baaf634
> > 
> > At this point, syslinux_run_command is using the equivalent of
> > create_args_and_load(), a function that is *not* negatively affected
> > by ALLOWOPTIONS.
> > 
> > The behavior was changed in 2013 to use load_kernel to *add* label
support:
> >
http://git.zytor.com/?p=syslinux/syslinux.git;a=commit;h=04f40bc55ed4f39d6c625b017bb16907f7d50c05
> > 
> > At this point the 8 or 9 com32 modules I listed earlier stopped
working
> > when ALLOWOPTIONS was set. This is a change from the previous 6 years
> > of behavior.
> > 
> > But, if we still have different views on this, it looks like
ALLOWOPTIONS
> > is internally referred to as 'allowedit' in the menu code.
Perhaps
> > we can separate them there, maintaining an ALLOWOPTIONS' variable
for
> > load_kernel to check, but also adding a ALLOWEDIT option that the menu
> > can use to restrict the Tab to edit functionality.
> > 
> > Thoughts?
> > 
> 
> I do agree that the current behavior is most likely an inadvertent
> regression.
> 
> 	-hpa
> 
 
As common user, my understanding of the relevant global directives 
is:

_ PROMPT: Whether (or not) to directly execute the DEFAULT (or UI if 
present) directive.
_ NOESCAPE: Whether (or not) to allow the usage of the [ESC / SHIFT / 
ALT / CAPS LOCK / SCROLL LOCK] keys.
_ NOCOMPLETE: Whether (or not) to allow the TAB key to display 
predefined labels in the command line.
_ IMPLICIT: Whether (or not) to limit the execution of commands to 
predefined labels only.
_ALLOWOPTIONS: Whether (or not) to allow the user to change 
(add/edit/erase) the command line _arguments_.

There are more global directives, but those are the relevant ones for 
this case.

Fortunately, there is no mention about acting over a specific type of 
kernels (or not to act on others). In case a global directive is 
related to some specific type of "anything", that "anything"
is
specifically used as argument of the relevant command (FONT and 
KBDMAP global directives as examples), or is specifically mentioned 
in the definition of the directive (e.g. when related to labels).

I don't know what these directives used to do 10 years ago. I do know 
that they are currently acting according to what it is expected by 
the user.

As user, I don't see a reason to change these current behaviors, 
specially if the suggested change would differentiate the (global) 
behavior depending on type of kernel. What's next? Global directives 
behaving differently depending on zImage / bzImage / memdisk / c32 
module / Linux version?

If there were no alternative to a certain desired behavior, then I 
could understand the doubts (in fact, I could mention certain 
situations not being currently supported).

As you might have noticed, I am not talking about which function does 
what in the source code. I am just pointing out the current behavior 
experienced (and expected) by the user.

Regards,
Ady.

> As common user, my understanding of the relevant global directives 
> is:
> 
> _ PROMPT: Whether (or not) to directly execute the DEFAULT (or UI if 
> present) directive.
 
I want to correct the way I previously formulated the PROMPT 
directive.
_ PROMPT: Whether (or not) to directly execute the DEFAULT directive; 
only valid if the UI directive is not used.

In my prior email I formulated the expression incorrectly.

This correction still doesn't change the main point of my email, but 
I wanted to clarify it just in case someone takes the prior 
description of the PROMPT directive as valid.

Regards,
Ady.