[syslinux] suggestions for global APPEND consistency

[Ady]

> On Tue, Feb 12, 2013 at 3:17 PM, Ady <ady-sf at hotmail.com> wrote:
> > Hello Syslinux Team,
> >
> > I have some suggestions / requests regarding global APPEND commands.
> > These would make the behavior more consistent and more useful for
> > practical cases.
> >
> > 1_ Add some functionality equivalent to "APPEND -" to the command
> > prompt.
> >
> > 2_ Activate the functionality of ONERROR from [vesa]menu.c32 too.
> > Currently, ONERROR only works from the command prompt.
> 
> This seems like it's a separate discussion and a possible bug.  I'm
> guessing you observe this when (vesa)menu.c32 is used as UI or DEFAULT
> with a reduced TIMEOUT.  Perhaps "ONERROR menu.c32 errmenu.cfg" will
> show different behavior (in which case it's likely a config error not
> a bug).

Well, it is not a completely separate discussion. I observed the 
ONERROR inconsistency while testing global APPEND. Starting from 
menu.c32 and selecting an entry, the ONERROR statement seems to be 
not activated (but I could be making a mistake or a wrong 
assumption). If the same entry is tried from CLI, ONERROR acts.

The "relation" between ONERROR and the global append tests I was 
performing is that ONERROR "merges" its statement with the specific 
command from the specific entry. Although this is not the same as 
merging an alternative "global append" (which is currently not 
possible), it was part of my tests.

BTW, regarding the recently reported bug about running "label 
options" from CLI... I also saw the same problem while testing global 
append statements.

I agree that suggestions #1 and #2 could be separated from the rest, 
but they are all related to my experience / tests of global APPEND.

> 
> > 3_ Add a new directive that would function as global APPEND, with the
> > difference that it could be merged with specific KERNEL+INITRD+APPEND
> > commands (those that are used after LABEL). *Just for the purpose of
> > this email*, let's call it [MENU] GAPPEND (Please forgive me if using
> > the word "MENU" for this new suggested directive is not appropriate;
> > the concepts I post here are still applicable without this word, so I
> > will use [MENU] GAPPEND). The resulting generic command would be:
> > KERNEL + [MENU] GAPPEND + INITRD + APPEND (in this order). Any of the
> > four parts of this resulting command could be not-explicitly stated
> > in the cfg file.
> >
> > 4_ When pressing TAB on a LABEL in [vesa]menu.c32, the command line
> > should display ALL the resulting commands, including [MENU] GAPPEND.
> 
> That's the trick about global APPENDs: they are always applied unless
> there's a different APPEND.

My request / suggestion #4 just says that if you start from 
[vesa]menu.c32, select an entry and press TAB, it would be useful to 
see the full resulting command, including my suggested [MENU] GAPPEND 
part, instead of _silently_ executing it without showing it in the 
command prompt. To "correctly" understand my intention, suggestion #5 
is also essential.

This of course is not possible when you start with the prompt and you 
manually type in the command. I hope this hints to one of the reasons 
for me to suggest [MENU] GAPPEND as a new directive.


> 
> > 5_ For [MENU] GAPPEND, if the resulting command is manually edited in
> > the boot prompt, the edition should be respected (as oppose to
> > silently forcing [MENU] GAPPEND).
> 
> As I've stated, I feel the most useful option is to either
> A) remove the global APPENDs
> B) discourage users from using them.

I disagree. The most useful for users, IMHO, would be implementing a 
different directive, which I called it "[MENU] GAPPEND" for the 
purpose of this email thread, which would behave more consistently 
(and it is not exactly the same as the current global append).

Suggestions #3 to #5 (plus, applying "APPEND -" to "[MENU] GAPPEND" 
too, call it #6 if you want) are all independent of the current state 
of global APPEND, and they act as a whole.

Note that I am suggesting a new directive, in part so not to break 
the current global APPEND behavior (whether the current global append 
usage would be discouraged or not).

TIA,
Ady.