[Suggestion] LILO-like direct menu item access

[Suggestion] LILO-like direct menu item access

[Marc-Jano Knopp]

Hi all!

I'm only an end user, but didn't find another way to suggest something
for GRUB 2 except for this mailing list, so here we go:

There is one reason I do not employ GRUB everywhere: With LILO, you
can blindly select a specific menu item, which you cannot with GRUB
(at least with GRUB 0.92).

I can assign numbers or different letters to the LILO menu items and so
directly and blindly access them, independently from the current
selection bar position, not having to switch on a monitor (or even
actually have one attached). And at least a year ago or so, I could not
find anything in the GRUB documentation to make this work.

Now, while you're at it, could you add such a feature to GRUB 2?
Especially having letters to select menu items would be very helpful
(l = Linux, f = FreeBSD, n = NetBSD, d = DOS, ...).

Maybe this could be done by introducing a LILO-menu-mode acting
the way I described, with e.g. special escape- or control-key-
sequences to directly select LILO-menu- and GRUB-mode (ESC-g/l or
whatever), with the default mode being definable in /etc/grub.conf,
errrr, /boot/grub/menu.lst or whatever.

Oh, and... while this might be possible using some kind of script
(just read shortly about a pre-alpha scripting engine), a touch of
user-friendliness like a simple grub.conf entry like "key", e.g.

  title SuSE 7.3 (2.4.29)
  root (hd0,2)
  kernel /boot/vmlinuz root=/dev/sda1 vga=extended rootflags=data=journal
  key l

would be nice. :-)


Best regards

  Marc-Jano

P.S.: If this behavior is already possible with GRUB legacy, please let
      me know how!

Re: [Suggestion] LILO-like direct menu item access && scripting

[Serbinenko Vladimir]

Marc-Jano Knopp wrote:

>Hi all!
>
>I'm only an end user, but didn't find another way to suggest something
>for GRUB 2 except for this mailing list, so here we go:
>
>There is one reason I do not employ GRUB everywhere: With LILO, you
>can blindly select a specific menu item, which you cannot with GRUB
>(at least with GRUB 0.92).
>
>I can assign numbers or different letters to the LILO menu items and so
>directly and blindly access them, independently from the current
>selection bar position, not having to switch on a monitor (or even
>actually have one attached). And at least a year ago or so, I could not
>find anything in the GRUB documentation to make this work.
>
>Now, while you're at it, could you add such a feature to GRUB 2?
>Especially having letters to select menu items would be very helpful
>(l = Linux, f = FreeBSD, n = NetBSD, d = DOS, ...).
>
>Maybe this could be done by introducing a LILO-menu-mode acting
>the way I described, with e.g. special escape- or control-key-
>sequences to directly select LILO-menu- and GRUB-mode (ESC-g/l or
>whatever), with the default mode being definable in /etc/grub.conf,
>errrr, /boot/grub/menu.lst or whatever.
>
>  
>
It will be better if when you press the buttons GRUB highlight
the corresponding entries. Like it's done in some indexes. The
problem are the touchs 'c' and 'e'. Perhaps it's good idea to  move to
C-c  and  C-e

>Oh, and... while this might be possible using some kind of script
>(just read shortly about a pre-alpha scripting engine),
>
About engine:
I made it GCS compatible, commented it and reorganized.
Main current problem is a lack of testing. So if you find a bug or have
a suggestion don't hesitate to contact me by this list or in private.
The other problem is the mails: the patch is quite big and is blocked
somewhere (I sent it to grub-devel but haven't received). If somebody
is interested he can send me private e-email and I'll send the patch in 
private

> a touch of
>user-friendliness like a simple grub.conf entry like "key", e.g.
>
>  title SuSE 7.3 (2.4.29)
>  root (hd0,2)
>  kernel /boot/vmlinuz root=/dev/sda1 vga=extended rootflags=data=journal
>  key l
>
>would be nice. :-)
>
>  
>
Not at all because this syntax will mean that key is executed
before choosing entry that I don't like. I propose the following
syntaxes (I'm waiting for your suggestions which to use):
entry "SuSE 7.3 (2.4.29)":l
{
    root (hd0,2)
    kernel /boot/vmlinuz root=/dev/sda1 vga=extended rootflags=data=journal
}
When you press 'l' it highlights  this entry
entry "SuSE 7.3 (2.4.29)":suse
{
    root (hd0,2)
    kernel /boot/vmlinuz root=/dev/sda1 vga=extended rootflags=data=journal
}
When you type suse it highlights it

>Best regards
>
>  Marc-Jano
>
>P.S.: If this behavior is already possible with GRUB legacy, please let
>      me know how!
>
>
>_______________________________________________
>Grub-devel mailing list
>Grub-devel@gnu.org
>http://lists.gnu.org/mailman/listinfo/grub-devel
>
>
>  
>

Re: [Suggestion] LILO-like direct menu item access

[Marco Gerards]

Marc-Jano Knopp <pub_ml_grub-devel@marc-jano.de> writes:

> Hi all!
>
> I'm only an end user, but didn't find another way to suggest something
> for GRUB 2 except for this mailing list, so here we go:

This is the right list for anything related to GRUB 2. :)

> There is one reason I do not employ GRUB everywhere: With LILO, you
> can blindly select a specific menu item, which you cannot with GRUB
> (at least with GRUB 0.92).
>
> I can assign numbers or different letters to the LILO menu items and so
> directly and blindly access them, independently from the current
> selection bar position, not having to switch on a monitor (or even
> actually have one attached). And at least a year ago or so, I could not
> find anything in the GRUB documentation to make this work.
>
> Now, while you're at it, could you add such a feature to GRUB 2?
> Especially having letters to select menu items would be very helpful
> (l = Linux, f = FreeBSD, n = NetBSD, d = DOS, ...).

It's a nice feature to have, but perhaps this can be made more
generic.  For example, people have requested support for other ways to
control the menu and select an item.  For example it could be made
possible to use a remote control or so.

The remote control is a silly example (ehm, right?) but the keyboard
should not be the only way to select a menu entry directly.  So I hope
the feature can be made a bit more generic *somehow*.

It's a feature I would personally like and I have seen requests for
such feature or features like this before.  If no one does not like
the feature, I will add it on the todo on the wiki later this week.

Thanks,
Marco

Re: [Suggestion] LILO-like direct menu item access && scripting

[Marco Gerards]

Serbinenko Vladimir <serbinenko.vova@list.ru> writes:

> Not at all because this syntax will mean that key is executed
> before choosing entry that I don't like. I propose the following
> syntaxes (I'm waiting for your suggestions which to use):

In that case you just should not press that key. :)

There is only the problem of key collisions (c is used for the
console, for example).  Perhaps 0-9, c-a and c-z can be used or so, I
personally don't care too much about this.

But it would be nice, IMHO, if it was clear which entry has which
hotkey.  Perhaps the title can be followed by the key in some
different color or so?

> entry "SuSE 7.3 (2.4.29)":l
> {
>     root (hd0,2)
>     kernel /boot/vmlinuz root=/dev/sda1 vga=extended rootflags=data=journal
> }

Personally I would prefer something like:

entry "SuSE 7.3 (2.4.29)" key="1"
{
    root (hd0,2)
    kernel /boot/vmlinuz root=/dev/sda1 vga=extended rootflags=data=journal
}

Or we could just give *every* menu item a hotkey and make it
configurable to make it visual (like I described above) or not.

Thanks,
Marco

Re: [Suggestion] LILO-like direct menu item access && scripting

[Marc-Jano Knopp]

On Mon, 07 Feb 2005 at 17:33 (+0000), Marco Gerards wrote:
> Serbinenko Vladimir <serbinenko.vova@list.ru> writes:
> 
> > Not at all because this syntax will mean that key is executed
> > before choosing entry that I don't like. I propose the following
> > syntaxes (I'm waiting for your suggestions which to use):
> 
> In that case you just should not press that key. :)
> 
> There is only the problem of key collisions (c is used for the
> console, for example).  Perhaps 0-9, c-a and c-z can be used or so, I
> personally don't care too much about this.

Strange, both of you don't seem to like the idea of a menu mode, and
rather accept restrictions in the choice of menu item letters. I would
rather install Windows than accept such an inconsistency or restriction.
;-)

Though I'm out of time for doing this myself, it doesn't seem too
difficult to introduce a menu mode in GRUB: a flag, e.g.
lilo_menu_mode and possibly a single if-statement to choose between
the two command parsers and/or tables.

Or am I too optimistic?

As I mentioned before, there should be a way to absolutely (not
relatively) select this LILO menu mode, so that you can really blindly
work with it. So a toggle-menu-mode command/key (alone) will not
suffice, there should be two different commands/keys for selecting
the native GRUB command mode and the LILO menu mode.

Additionally, the LILO menu mode could be indicated by a(n) (un)lit
CapsLock LED, which most PC and many workstation keyboards have.

And of course, the current mode should be printed well visible on
the screen (inverted "LILO MENU MODE" or something).


Finally, we need a grub.conf entry for choosing the default mode:

  lilomenumode on

Done. :-)


Of course, the lilo menu behavior is also possible without an extra
mode, but then you have use Ctrl/Alt/whatever for either the GRUB
commands or the LILO selection, and in both cases it's unnecessarily
cumbersome (especially, if a menu item could be selected by a whole
/string/, not a just a single letter/cipher).

If you insist on modeless operation (oh, c'mon! :-}, please us Alt
instead of Ctrl; it's much easier to use, as the left thumb isn't
used elsewhere (the space bar can be operated with the right thumb
as well) - as opposed to the left pinky. :-)


> But it would be nice, IMHO, if it was clear which entry has which
> hotkey.  Perhaps the title can be followed by the key in some
> different color or so?

Hmm... I think the other way round would be nicer, as that's the
usual way to do it (and everything is naturally aligned nicely then).
(I think in LILO menus the order is the same, i.e. first letters, then
name of the menu item).

Then again, the best solution would be a user definable (in
grub.conf) format string with %h for hotkey/hot"string" and %n for the
menu item name etc.


> > entry "SuSE 7.3 (2.4.29)":l
> > {
> >     root (hd0,2)
> >     kernel /boot/vmlinuz root=/dev/sda1 vga=extended rootflags=data=journal
> > }
> 
> Personally I would prefer something like:
> 
> entry "SuSE 7.3 (2.4.29)" key="1"
> {
>     root (hd0,2)
>     kernel /boot/vmlinuz root=/dev/sda1 vga=extended rootflags=data=journal
> }

I'd prefer the latter, too, as it's nicer to read, indeed. But the
first example is also still quite readable, especially when you choose
the keys/strings appropriately, so you can implement whatever you like.


Oh, of course it's right what Vladimir wrote: the hotkey should not
execute a menu item directly, but move the selection bar over it, so
that you can execute it with [Return]. The word "select" is too
ambiguous here.


It would be nice to have some kind of incremental search feature, just
as IIRC LILO offers (I think that's what Vladimir meant), but the
1-letter/cipher selection would be okay, too.


> Or we could just give *every* menu item a hotkey and make it
> configurable to make it visual (like I described above) or not.

Hmm... you mean every item has an implicit, automatically generated
hotkey unless the user defines hotkeys of his own? Well, as long as
it's printed somewhere, why not. But I think that there should be a
way to undefine these automatically given hotkeys for each menu item
then - at least I would like to be able to do so, as otherwise I'd
feel like losing control a little, and then I could also install
Windows. :-)


Best regards

  Marc-Jano

Re: [Suggestion] LILO-like direct menu item access && scripting

[Serbinenko Vladimir]

What if additionally make a command "runentry" And then you could 
blindly go to console and execute
grub>runentry suse
Marc-Jano Knopp wrote:
[...]

Re: [Suggestion] LILO-like direct menu item access && scripting

[Yoshinori K. Okuji]

On Monday 07 February 2005 15:43, Serbinenko Vladimir wrote:
> private. The other problem is the mails: the patch is quite big and
> is blocked somewhere (I sent it to grub-devel but haven't received).
> If somebody is interested he can send me private e-email and I'll
> send the patch in private

Please don't send it by e-mail here. Is it difficult for you to put the 
patch somewhere? If you have no public place yourself, you can use 
Savannah.

Okuji

Re: [Suggestion] LILO-like direct menu item access && scripting

[Serbinenko Vladimir]

Yoshinori K. Okuji wrote:

>On Monday 07 February 2005 15:43, Serbinenko Vladimir wrote:
>  
>
>>private. The other problem is the mails: the patch is quite big and
>>is blocked somewhere (I sent it to grub-devel but haven't received).
>>If somebody is interested he can send me private e-email and I'll
>>send the patch in private
>>    
>>
>
>Please don't send it by e-mail here. Is it difficult for you to put the 
>patch somewhere? If you have no public place yourself, you can use 
>Savannah.
>
>  
>
Here it is http://phcoder.narod.ru/bash.diff. I know that it's slow
hosting but I haven't received the confirmation e-mail from faster one yet

Re: [Suggestion] LILO-like direct menu item access && scripting

[Marc-Jano Knopp]

On Tue, 08 Feb 2005 at 11:25 (+0100), Serbinenko Vladimir wrote:

> What if additionally make a command "runentry" And then you could 
> blindly go to console and execute
> grub>runentry suse

Not good, I think. What if I want to append a boot parameter to a
menu entry (like Linux runlevel)? Then I have to select the entry
first, not directly run it.

Now please don't suggest a command "selectentry". :-}

There's no problem which such commands, except that they are a little
too long IMHO. If there was a shortcut of some kind...

Still, no-one has told me yet why implementing a LILO menu mode is a
problem. Is it a technical problem? Then refactor your code. ;-) Is
it an ergonomical problem, does it introduce something the user does
not expect?

Please talk to me! :-)


Best regards

  Marc-Jano

Re: [Suggestion] LILO-like direct menu item access && scripting

[Marco Gerards]

Marc-Jano Knopp <pub_ml_grub-devel@marc-jano.de> writes:

> On Mon, 07 Feb 2005 at 17:33 (+0000), Marco Gerards wrote:
>> Serbinenko Vladimir <serbinenko.vova@list.ru> writes:
>> 
>> > Not at all because this syntax will mean that key is executed
>> > before choosing entry that I don't like. I propose the following
>> > syntaxes (I'm waiting for your suggestions which to use):
>> 
>> In that case you just should not press that key. :)
>> 
>> There is only the problem of key collisions (c is used for the
>> console, for example).  Perhaps 0-9, c-a and c-z can be used or so, I
>> personally don't care too much about this.
>
> Strange, both of you don't seem to like the idea of a menu mode, and
> rather accept restrictions in the choice of menu item letters. I would
> rather install Windows than accept such an inconsistency or restriction.

The other keys have a meaning already and because of that those keys
can not be used.  But what do you mean with menu mode?  I did not say
in my email that I did not like the idea, right, so what makes you
think that.

> Though I'm out of time for doing this myself, it doesn't seem too
> difficult to introduce a menu mode in GRUB: a flag, e.g.
> lilo_menu_mode and possibly a single if-statement to choose between
> the two command parsers and/or tables.

Why two menus if the main menu can get hotkey support?

> Or am I too optimistic?
>
> As I mentioned before, there should be a way to absolutely (not
> relatively) select this LILO menu mode, so that you can really blindly
> work with it. So a toggle-menu-mode command/key (alone) will not
> suffice, there should be two different commands/keys for selecting
> the native GRUB command mode and the LILO menu mode.

Ehm.  You are changing your ideas now.  In the previous email you
described something to bind a key to a menu item, now you are talking
about a new menu?

> Of course, the lilo menu behavior is also possible without an extra
> mode, but then you have use Ctrl/Alt/whatever for either the GRUB
> commands or the LILO selection, and in both cases it's unnecessarily
> cumbersome (especially, if a menu item could be selected by a whole
> /string/, not a just a single letter/cipher).

Using a whole string seems silly to me as well. :)

> If you insist on modeless operation (oh, c'mon! :-}, please us Alt
> instead of Ctrl; it's much easier to use, as the left thumb isn't
> used elsewhere (the space bar can be operated with the right thumb
> as well) - as opposed to the left pinky. :-)

Have you thought about how to implement that as well? :)

This will be quite hard.  When reading a key you just know about
ctrl.  Reading alt sucks, especially for portability.
>
>> But it would be nice, IMHO, if it was clear which entry has which
>> hotkey.  Perhaps the title can be followed by the key in some
>> different color or so?
>
> Hmm... I think the other way round would be nicer, as that's the
> usual way to do it (and everything is naturally aligned nicely then).
> (I think in LILO menus the order is the same, i.e. first letters, then
> name of the menu item).

The other way around?  Can you describe that please?

> Hmm... you mean every item has an implicit, automatically generated
> hotkey unless the user defines hotkeys of his own? Well, as long as
> it's printed somewhere, why not. But I think that there should be a
> way to undefine these automatically given hotkeys for each menu item
> then - at least I would like to be able to do so, as otherwise I'd
> feel like losing control a little, and then I could also install
> Windows. :-)

It seems you really are looking for reasons to install windows, no?

--
Marco

Re: [Suggestion] LILO-like direct menu item access && scripting

[Marco Gerards]

Marc-Jano Knopp <pub_ml_grub-devel@marc-jano.de> writes:

> Still, no-one has told me yet why implementing a LILO menu mode is a
> problem. Is it a technical problem? Then refactor your code. ;-) Is
> it an ergonomical problem, does it introduce something the user does
> not expect?

For me that would be:

1) GRUB is not lilo.  It can have similar features, but that does not
   mean it should work perfectly the same.

2) Who will work on this?  I won't write lilo menu mode, that's for
   sure :).  GRUB is really modular, you could just write a module for
   this, I guess.  Even if it would be written, it won't automatically
   mean it is what we want (see #1).

3) Why writing more code, even a new menu, if it can be perfectly
   added to the current menu?

--
Marco

Re: [Suggestion] LILO-like direct menu item access && scripting

[Marc-Jano Knopp]

On Tue, 08 Feb 2005 at 21:48 (+0000), Marco Gerards wrote:
> Marc-Jano Knopp <pub_ml_grub-devel@marc-jano.de> writes:
> > On Mon, 07 Feb 2005 at 17:33 (+0000), Marco Gerards wrote:
[...]

I see that the whole problem is a misunderstanding about what we
mean by LILO menu mode - I'm sorry if I explained it too ambiguously
and I will hereby not just clarify, but simplify this issue *a lot*:


In GRUB, one should be able to move the selection bar absolutely
to a specific menu item by means of hotkeys (or "hotstrings").

I propose to have the single-letter command 's' (I hope it's not
bound yet) for choosing a specific menu item by hotkey.

Usage:

  1. Hit 's'
  2. Hit hotkey of wanted menu item (e.g. 'l' for Linux)

  The wanted menu item is now selected (not executed).

If one wants to use "hotstrings" to select a specific menu item,
step 2 needs pressing [Return] after entering the string.

That's all!

Now *that* should be easy to code (for a GRUB developer :-).


[...]
> >> But it would be nice, IMHO, if it was clear which entry has which
> >> hotkey.  Perhaps the title can be followed by the key in some
> >> different color or so?
> >
> > Hmm... I think the other way round would be nicer, as that's the
> > usual way to do it (and everything is naturally aligned nicely then).
> > (I think in LILO menus the order is the same, i.e. first letters, then
> > name of the menu item).
> 
> The other way around?  Can you describe that please?

Suggested way:

  menuitemtitle1 hotkey1
  menuitemtitle2 hotkey2
  menuitemtitle3 hotkey3

My (and LILO's (and Carlito's)) way:

  hotkey1 menuitemtitle1
  hotkey2 menuitemtitle2
  hotkey3 menuitemtitle3

I guess a run-time-interpreted format string for menu item formatting
would be best.


[...]
> It seems you really are looking for reasons to install windows, no?

Definitely not! :-)


Best regards

  Marc-Jano

Re: [Suggestion] LILO-like direct menu item access && scripting

[Serbinenko Vladimir]

Marc-Jano Knopp wrote:

>On Tue, 08 Feb 2005 at 21:48 (+0000), Marco Gerards wrote:
>  
>
>>Marc-Jano Knopp <pub_ml_grub-devel@marc-jano.de> writes:
>>    
>>
>>>On Mon, 07 Feb 2005 at 17:33 (+0000), Marco Gerards wrote:
>>>      
>>>
>[...]
>
>I see that the whole problem is a misunderstanding about what we
>mean by LILO menu mode - I'm sorry if I explained it too ambiguously
>and I will hereby not just clarify, but simplify this issue *a lot*:
>
>
>In GRUB, one should be able to move the selection bar absolutely
>to a specific menu item by means of hotkeys (or "hotstrings").
>
>I propose to have the single-letter command 's' (I hope it's not
>bound yet) for choosing a specific menu item by hotkey.
>
>Usage:
>
>  1. Hit 's'
>  
>
I would prefer that all keys with special meaning will be
C-something (with ctrl). And then all normal keys will be
for choice only. So there is no need for 's'

>  2. Hit hotkey of wanted menu item (e.g. 'l' for Linux)
>
>  The wanted menu item is now selected (not executed).
>
>If one wants to use "hotstrings" to select a specific menu item,
>step 2 needs pressing [Return] after entering the string.
>
>That's all!
>
>Now *that* should be easy to code (for a GRUB developer :-).
>
>
>[...]
>  
>
>>>>But it would be nice, IMHO, if it was clear which entry has which
>>>>hotkey.  Perhaps the title can be followed by the key in some
>>>>different color or so?
>>>>        
>>>>
>>>Hmm... I think the other way round would be nicer, as that's the
>>>usual way to do it (and everything is naturally aligned nicely then).
>>>(I think in LILO menus the order is the same, i.e. first letters, then
>>>name of the menu item).
>>>      
>>>
>>The other way around?  Can you describe that please?
>>    
>>
>
>Suggested way:
>
>  menuitemtitle1 hotkey1
>  menuitemtitle2 hotkey2
>  menuitemtitle3 hotkey3
>
>My (and LILO's (and Carlito's)) way:
>
>  hotkey1 menuitemtitle1
>  hotkey2 menuitemtitle2
>  hotkey3 menuitemtitle3
>
>  
>
Have you read about current GRUB2 menu syntax?
I think the best syntax will be:
entry "SuSE Linux" sequence="suse"
{
    ....
}
Other thing that I would like to discuss is how to clear entered string.
E.g. if I entered "win32" but then I thought that it must die and want 
linux.
How can I clear it fast without using backspace to enter "mdk"

>I guess a run-time-interpreted format string for menu item formatting
>would be best.
>
>
>  
>
I'll write syntax interpreting and perhaps whole thing because menu 
parsing is
integrated with scripting and nobody knows it better then me

P.S. What is your opinion about scripting(till now I've heard no comments)?

Re: [Suggestion] LILO-like direct menu item access && scripting

[Yoshinori K. Okuji]

I think I have already described my idea about shortcut keys in this 
list. Please search the archive before starting a new discussion.

Okuji

Re: [Suggestion] LILO-like direct menu item access && scripting

[Marc-Jano Knopp]

On Wed, 09 Feb 2005 at 11:21 (+0100), Serbinenko Vladimir wrote:
> Marc-Jano Knopp wrote:
> >On Tue, 08 Feb 2005 at 21:48 (+0000), Marco Gerards wrote:
> >>Marc-Jano Knopp <pub_ml_grub-devel@marc-jano.de> writes:
> >>>On Mon, 07 Feb 2005 at 17:33 (+0000), Marco Gerards wrote:
[...]
> >In GRUB, one should be able to move the selection bar absolutely
> >to a specific menu item by means of hotkeys (or "hotstrings").
> >
> >I propose to have the single-letter command 's' (I hope it's not
> >bound yet) for choosing a specific menu item by hotkey.
> >
> >Usage:
> >
> > 1. Hit 's'
> >
> I would prefer that all keys with special meaning will be
> C-something (with ctrl). And then all normal keys will be
> for choice only. So there is no need for 's'

That would be an alternative. But you cannot use 'k'/'j' for
moving the selection bar up/down then, which would be nice to do,
as a lot of programs use these vi bindings, and one can get really
used to it. But I could live with it, as long as all key bindings
are remappable. :-)


[...]
> >>>>But it would be nice, IMHO, if it was clear which entry has which
> >>>>hotkey.  Perhaps the title can be followed by the key in some
> >>>>different color or so?
> >>>>       
> >>>>
> >>>Hmm... I think the other way round would be nicer, as that's the
> >>>usual way to do it (and everything is naturally aligned nicely then).
> >>>(I think in LILO menus the order is the same, i.e. first letters, then
> >>>name of the menu item).
[...]
> >My (and LILO's (and Carlito's)) way:
> >
> > hotkey1 menuitemtitle1
> > hotkey2 menuitemtitle2
> > hotkey3 menuitemtitle3
> >
> Have you read about current GRUB2 menu syntax?
> I think the best syntax will be:
> entry "SuSE Linux" sequence="suse"
> {
>    ....
> }

Misunderstanding: He talked about the display of the menu and its keys,
not about configuring the keys. The syntax above looks okay to me.


> Other thing that I would like to discuss is how to clear entered string.
> E.g. if I entered "win32" but then I thought that it must die and want 
> linux.
> How can I clear it fast without using backspace to enter "mdk"

Ctrl-U? (Or Ctrl-A, Ctrl-K)
Or Escape?


> >I guess a run-time-interpreted format string for menu item formatting
> >would be best.
> >
> I'll write syntax interpreting and perhaps whole thing because menu 
> parsing is
> integrated with scripting and nobody knows it better then me

Okay.


> P.S. What is your opinion about scripting(till now I've heard no comments)?

I cannot really comment on it, because I'm not so deeply involved in
development (i.e. not at all :-}. In general I can say: give the user
maximum power. So, scripting sounds like a good idea to me.

(Btw.: What's "GCS"? Couldn't find anything in the GRUB docs.)


Best regards

  Marc-Jano

Re: [Suggestion] LILO-like direct menu item access && scripting

[Marc-Jano Knopp]

On Thu, 10 Feb 2005 at 20:24 (+0100), Yoshinori K. Okuji wrote:
> I think I have already described my idea about shortcut keys in this 
> list. Please search the archive before starting a new discussion.

I'm sorry, I had searched for "hotkeys" before, yielding no results.
Now that I see you call them shortcut keys, I've found your mail in
the archive:

,----[ http://lists.gnu.org/archive/html/grub-devel/2004-07/msg00043.html ]---
| - User-definable shortcuts
| 
| You can define a keymap for shortcuts:
| 
| title --key=1 Debian GNU/Hurd
| ...
| 
| title --key=2 Debian GNU/Linux
| ...
`----

But as your mail left a few things open (Select or execute? Normal
keys or keys with modifier? Single-letter-keys or strings?), the
discussion about this would have had to be continued anyway. :-)


Best regards

  Marc-Jano

Re: [Suggestion] LILO-like direct menu item access && scripting

[Yoshinori K. Okuji]

On Thursday 10 February 2005 22:51, Marc-Jano Knopp wrote:
> But as your mail left a few things open (Select or execute? Normal
> keys or keys with modifier? Single-letter-keys or strings?), the
> discussion about this would have had to be continued anyway. :-)

I prefer to execute it when a shortcut key is pressed. Why not?

I don't think strings are very useful. The purpose of shortcut keys is 
to select something instantly, then it should be a single key press.

All possible keys should be able to be assigned shortcuts. But, my idea 
is not only for shortcuts. The functions of keys are hardcoded in the 
current implementation, but they should be configurable. For instance, 
if the user wants to use C-c to enter the command-line interface and 
use c to select a menu entry, this should be supported.

Okuji

Re: [Suggestion] LILO-like direct menu item access && scripting

[Marc-Jano Knopp]

On Fri, 11 Feb 2005 at 10:38 (+0100), Yoshinori K. Okuji wrote:
> On Thursday 10 February 2005 22:51, Marc-Jano Knopp wrote:
> > But as your mail left a few things open (Select or execute? Normal
> > keys or keys with modifier? Single-letter-keys or strings?), the
> > discussion about this would have had to be continued anyway. :-)
> 
> I prefer to execute it when a shortcut key is pressed. Why not?

Because then it would not be possible to edit menu items blindly.
For example, I could not blindly add boot parameters to the Linux
kernel (runlevel, root=<whatever>, etc.) to override the default
settings (which I do, indeed, e.g. for my SCSI testing machine
which varying disks with varying partition layout connected, so that
fixed menu items don't help).


> I don't think strings are very useful. The purpose of shortcut keys is
> to select something instantly, then it should be a single key press.

But that's only implied by the /word/ "shortcut key". Being able to use
strings instead of single keys would make these shortcuts much more
mnemonic and thus easier to remember. E.g.

  l  - Linux 2.2
  l4 - Linux 2.4
  l6 - Linux 2.6
  f  - FreeBSD 3.x
  f4 - FreeBSD 4.x
  f5 - FreeBSD 5.x  

If you had only a single letter for selection, then you cannot choose
mnemonic shortcuts anymore, as e.g. '4' would collide for "Linux 2.4"
and "FreeBSD 4.x".


> All possible keys should be able to be assigned shortcuts. But, my idea 
> is not only for shortcuts. The functions of keys are hardcoded in the 
> current implementation, but they should be configurable. For instance, 
> if the user wants to use C-c to enter the command-line interface and 
> use c to select a menu entry, this should be supported.

This sounds good!

So I could say something like

  bind "s" select-entry-by-inputstring();

so that hitting 's' in the menu asks me for a string to select a menu
entry? Provided either a GRUB developer codes the function
select-entry-by-inputstring() or the user can do so easily by defining
the function in a configuration file.


Best regards

  Marc-Jano

Re: [Suggestion] LILO-like direct menu item access && scripting

[Serbinenko Vladimir]

Marc-Jano Knopp wrote:

>On Fri, 11 Feb 2005 at 10:38 (+0100), Yoshinori K. Okuji wrote:
>  
>
>>On Thursday 10 February 2005 22:51, Marc-Jano Knopp wrote:
>>    
>>
>>>But as your mail left a few things open (Select or execute? Normal
>>>keys or keys with modifier? Single-letter-keys or strings?), the
>>>discussion about this would have had to be continued anyway. :-)
>>>      
>>>
>>I prefer to execute it when a shortcut key is pressed. Why not?
>>    
>>
>
>Because then it would not be possible to edit menu items blindly.
>For example, I could not blindly add boot parameters to the Linux
>kernel (runlevel, root=<whatever>, etc.) to override the default
>settings (which I do, indeed, e.g. for my SCSI testing machine
>which varying disks with varying partition layout connected, so that
>fixed menu items don't help).
>
>
>  
>
I think the best choice to do it is to bind a key like C-p to add 
parameters to the entry. Then theese parameters will be accessible as 
$1, $2, ... ($0 is a label of menu entry)

Re: [Suggestion] LILO-like direct menu item access && scripting

[Marc-Jano Knopp]

On Fri, 11 Feb 2005 at 15:34 (+0100), Serbinenko Vladimir wrote:
> Marc-Jano Knopp wrote:
> >On Fri, 11 Feb 2005 at 10:38 (+0100), Yoshinori K. Okuji wrote:
> >>On Thursday 10 February 2005 22:51, Marc-Jano Knopp wrote:
> >>
> >>>But as your mail left a few things open (Select or execute? Normal
> >>>keys or keys with modifier? Single-letter-keys or strings?), the
> >>>discussion about this would have had to be continued anyway. :-)
> >>>     
> >>I prefer to execute it when a shortcut key is pressed. Why not?
> >
> >Because then it would not be possible to edit menu items blindly.
> >For example, I could not blindly add boot parameters to the Linux
> >kernel (runlevel, root=<whatever>, etc.) to override the default
> >settings (which I do, indeed, e.g. for my SCSI testing machine
> >which varying disks with varying partition layout connected, so that
> >fixed menu items don't help).
> >
> I think the best choice to do it is to bind a key like C-p to add 
> parameters to the entry. Then theese parameters will be accessible as 
> $1, $2, ... ($0 is a label of menu entry)

Accessible to whom or what?

My scenario would be something like this:

1. Hit 's' to enter select-menu-entry-by-name mode (optional)
2. Type "linux" and hit [Return] to select (not execute) menu item
   "Linux 2.4"
3. Hit 'e' to edit. Now the cursor could be at the end of the line
   by default, so that I just need to type for example:
4. " root=/dev/sdf" [Return]
5. Hit [Return] again (or 'b') to boot.


Best regards

  Marc-Jano

Re: [Suggestion] LILO-like direct menu item access && scripting

[Serbinenko Vladimir]

Marc-Jano Knopp wrote:

>On Fri, 11 Feb 2005 at 15:34 (+0100), Serbinenko Vladimir wrote:
>  
>
>>Marc-Jano Knopp wrote:
>>    
>>
>>>On Fri, 11 Feb 2005 at 10:38 (+0100), Yoshinori K. Okuji wrote:
>>>      
>>>
>>>>On Thursday 10 February 2005 22:51, Marc-Jano Knopp wrote:
>>>>
>>>>        
>>>>
>>>>>But as your mail left a few things open (Select or execute? Normal
>>>>>keys or keys with modifier? Single-letter-keys or strings?), the
>>>>>discussion about this would have had to be continued anyway. :-)
>>>>>    
>>>>>          
>>>>>
>>>>I prefer to execute it when a shortcut key is pressed. Why not?
>>>>        
>>>>
>>>Because then it would not be possible to edit menu items blindly.
>>>For example, I could not blindly add boot parameters to the Linux
>>>kernel (runlevel, root=<whatever>, etc.) to override the default
>>>settings (which I do, indeed, e.g. for my SCSI testing machine
>>>which varying disks with varying partition layout connected, so that
>>>fixed menu items don't help).
>>>
>>>      
>>>
>>I think the best choice to do it is to bind a key like C-p to add 
>>parameters to the entry. Then theese parameters will be accessible as 
>>$1, $2, ... ($0 is a label of menu entry)
>>    
>>
>
>Accessible to whom or what?
>
>  
>
To the scripts

>My scenario would be something like this:
>
>1. Hit 's' to enter select-menu-entry-by-name mode (optional)
>2. Type "linux" and hit [Return] to select (not execute) menu item
>   "Linux 2.4"
>3. Hit 'e' to edit. Now the cursor could be at the end of the line
>   by default, so that I just need to type for example:
>4. " root=/dev/sdf" [Return]
>5. Hit [Return] again (or 'b') to boot.
>
>  
>
The problem with this scenario is the determination of line by default 
especially for scripts. You can have a script that launches different 
kernels depending on condition or it can use function. Which line is the 
default one?

>Best regards
>
>  Marc-Jano
>
>
>_______________________________________________
>Grub-devel mailing list
>Grub-devel@gnu.org
>http://lists.gnu.org/mailman/listinfo/grub-devel
>
>
>  
>

Re: [Suggestion] LILO-like direct menu item access && scripting

[Marco Gerards]

Serbinenko Vladimir <serbinenko.vova@list.ru> writes:

> Yoshinori K. Okuji wrote:
>
>>On Monday 07 February 2005 15:43, Serbinenko Vladimir wrote:
>>  
>>
>>>private. The other problem is the mails: the patch is quite big and
>>>is blocked somewhere (I sent it to grub-devel but haven't received).
>>>If somebody is interested he can send me private e-email and I'll
>>>send the patch in private
>>>    
>>>
>>
>>Please don't send it by e-mail here. Is it difficult for you to put the 
>>patch somewhere? If you have no public place yourself, you can use 
>>Savannah.
>>
>>  
>>
> Here it is http://phcoder.narod.ru/bash.diff. I know that it's slow
> hosting but I haven't received the confirmation e-mail from faster one yet

I had a quick look at the patch for now.  Can you please explain in a
new thread how the patch globally works?  I will reply about the other
issues there as well.

There are still some things I would like to know:

- Why does everything happen with strings?

- Why are that many functions duplicated? (for example
  grub_bash_dupstr).

- What is that huge table with operators?  What kind of parser is it?
  I have never seen this in a top-down or bottom-up parser I have
  studied.

- How does the parser in general work?  So can you explain what
  happens when executing a script?  First you load the file.  Do you
  parse it, make pcode of it, run it directly?  How about error
  handling?

Thanks,
Marco

Scripting

[Serbinenko Vladimir]

Marco Gerards wrote:

>I had a quick look at the patch for now.  Can you please explain in a
>new thread how the patch globally works?  I will reply about the other
>issues there as well.
>
>There are still some things I would like to know:
>
>- Why does everything happen with strings?
>
>  
>
Because environment variables are the strings and it's not really
needed to convert them (excluding the calculating)

>- Why are that many functions duplicated? (for example
>  grub_bash_dupstr).
>
>  
>
In this case I just forgot about grub_strdup. But some other functions
have (nerly) the same names that string function but are adapted for
scripting (ex: grub_bash_strchr)

>- What is that huge table with operators?  
>
It's used to determinate which operator to execute (see
grub_bash_find_oper and grub_bash_eval_arith)

>What kind of parser is it?
>  
>
It's a direct parser with aritmetic subparser. Main parser is
grub_bash_execute, arithmetic subparser is grub_bash_eval_arith.
grub_bash_execute determinates the special cases (loops,conditions,
functions,...) for other cases (commands,assignments, function calling)
it calls grub_bash_split_tokens, grub_bash_expand_braces and
grub_bash_expand_dollar

>  I have never seen this in a top-down or bottom-up parser I have
>  studied.
>
>  
>
I don't like to write the things reffering every time to algorithm.
Genereally I take some ideas and I write myself, at my own.

>- How does the parser in general work?  
>
grub_bash_execute parses a line. If it detectes that end of the line is
not the end of command it calls getline function

>So can you explain what
>  happens when executing a script?  First you load the file.  Do you
>  parse it, make pcode of it, run it directly?
>
For the files I use grub_bash_exec_file. Only thing it does is
reading a file line by line and calling grub_bash_execute

>  How about error
>  handling?
>
>  
>
For now the problem is that not all posiible syntax errors are handled
correctly and more return checks have to be written. But first I'll write
line counting (only grub_bash_execute, grub_bash_list_execute and
grub_command_execute are affected)

>Thanks,
>Marco
>
>
>
>_______________________________________________
>Grub-devel mailing list
>Grub-devel@gnu.org
>http://lists.gnu.org/mailman/listinfo/grub-devel
>
>
>  
>

Re: [Suggestion] LILO-like direct menu item access && scripting

[Marc-Jano Knopp]

On Fri, 11 Feb 2005 at 18:13 (+0100), Serbinenko Vladimir wrote:
> Marc-Jano Knopp wrote:
> >On Fri, 11 Feb 2005 at 15:34 (+0100), Serbinenko Vladimir wrote:
> >>Marc-Jano Knopp wrote:
> >>>On Fri, 11 Feb 2005 at 10:38 (+0100), Yoshinori K. Okuji wrote:
> >>>>On Thursday 10 February 2005 22:51, Marc-Jano Knopp wrote:
> >>>>
> >>>>>But as your mail left a few things open (Select or execute? Normal
> >>>>>keys or keys with modifier? Single-letter-keys or strings?), the
> >>>>>discussion about this would have had to be continued anyway. :-)
> >>>>>
> >>>>I prefer to execute it when a shortcut key is pressed. Why not?
> >>>>       
> >>>Because then it would not be possible to edit menu items blindly.
> >>>For example, I could not blindly add boot parameters to the Linux
> >>>kernel (runlevel, root=<whatever>, etc.) to override the default
> >>>settings (which I do, indeed, e.g. for my SCSI testing machine
> >>>which varying disks with varying partition layout connected, so that
> >>>fixed menu items don't help).
> >>>
> >>I think the best choice to do it is to bind a key like C-p to add 
> >>parameters to the entry. Then theese parameters will be accessible as 
> >>$1, $2, ... ($0 is a label of menu entry)
> >
> >Accessible to whom or what?
> >
> To the scripts

Hm. What would that be good for?


> >My scenario would be something like this:
> >
> >1. Hit 's' to enter select-menu-entry-by-name mode (optional)
> >2. Type "linux" and hit [Return] to select (not execute) menu item
> >  "Linux 2.4"
> >3. Hit 'e' to edit. Now the cursor could be at the end of the line
> >  by default, so that I just need to type for example:
> >4. " root=/dev/sdf" [Return]
> >5. Hit [Return] again (or 'b') to boot.
> >
> The problem with this scenario is the determination of line by default 
> especially for scripts. You can have a script that launches different 
> kernels depending on condition or it can use function. Which line is the 
> default one?

Honestly: I don't understand what you mean. How would a script be
employed in the above scenario?

And why is it so difficult to determine the default line? Both the
index of the default line (i.e. e.g. menu item number 3) and its
initial value (like "kernel /boot/vmlinuz root=/dev/sda3") are known
to GRUB, and so should be known to the scripting engine, too.


Best regards

  Marc-Jano

Re: Scripting

[Marco Gerards]

Serbinenko Vladimir <serbinenko.vova@list.ru> writes:

>>- Why does everything happen with strings?
>>
> Because environment variables are the strings and it's not really
> needed to convert them (excluding the calculating)

Personally I don't like it too much.  I prefer keeping such
information in a struct or so.  You could how it in a string, but in
that case I would not use string operations that much.

>>- Why are that many functions duplicated? (for example
>>  grub_bash_dupstr).
>>
>>
>>
> In this case I just forgot about grub_strdup. But some other functions
> have (nerly) the same names that string function but are adapted for
> scripting (ex: grub_bash_strchr)

What is the difference with grub_strchr and grub_bash_strchr?  The
names give me the impression they are similar.

One this about the `grub_bash_' prefix.  I think it is a bit confusing
because the syntax is bash like, it is not bash.  I would prefer a
grub_script_ or grub_scripting_ prefix.

>> - What is that huge table with operators?
>>
> It's used to determinate which operator to execute (see
> grub_bash_find_oper and grub_bash_eval_arith)

Ok.

>>What kind of parser is it?
>>
>>
> It's a direct parser with aritmetic subparser. Main parser is
> grub_bash_execute, arithmetic subparser is grub_bash_eval_arith.
> grub_bash_execute determinates the special cases (loops,conditions,
> functions,...) for other cases (commands,assignments, function calling)
> it calls grub_bash_split_tokens, grub_bash_expand_braces and
> grub_bash_expand_dollar
>
>>  I have never seen this in a top-down or bottom-up parser I have
>>  studied.
> I don't like to write the things reffering every time to algorithm.
> Genereally I take some ideas and I write myself, at my own.

What do you mean?

The problem is that I like proven concepts.  And when you use a
commonly known parser design many people will be able to understand
it.  To me this is REALLY important.  I wonder what other developers
think of that.

>>So can you explain what
>>  happens when executing a script?  First you load the file.  Do you
>>  parse it, make pcode of it, run it directly?
>>
> For the files I use grub_bash_exec_file. Only thing it does is
> reading a file line by line and calling grub_bash_execute

So you run it while parsing, ok.

>>  How about error
>>  handling?
>>
> For now the problem is that not all posiible syntax errors are handled
> correctly and more return checks have to be written. But first I'll write
> line counting (only grub_bash_execute, grub_bash_list_execute and
> grub_command_execute are affected)

Ok.  Error handling is often not implemented in small parsers because
it can be really hard.  Don't forget error handling is really
important.  Syntax errors should not make the parser crash, hang,
etc.  Producing the right error and handling it right so GRUB remains
in a valid state, etc is a difficult task, I think.

Thanks,
Marco

Re: Scripting

[Serbinenko Vladimir]

Marco Gerards wrote:

>Serbinenko Vladimir <serbinenko.vova@list.ru> writes:
>
>  
>
>>>- Why does everything happen with strings?
>>>
>>>      
>>>
>>Because environment variables are the strings and it's not really
>>needed to convert them (excluding the calculating)
>>    
>>
>
>Personally I don't like it too much.  I prefer keeping such
>information in a struct or so.  You could how it in a string, but in
>that case I would not use string operations that much.
>
>  
>
I also but every laguage uses the variables. In our case they are in 
environment

>>>- Why are that many functions duplicated? (for example
>>> grub_bash_dupstr).
>>>
>>>
>>>
>>>      
>>>
>>In this case I just forgot about grub_strdup. But some other functions
>>have (nerly) the same names that string function but are adapted for
>>scripting (ex: grub_bash_strchr)
>>    
>>
>
>What is the difference with grub_strchr and grub_bash_strchr?  The
>names give me the impression they are similar.
>  
>
grub_bash_strchr doen't consider characters that are quoted, escaped or 
in brackets

>One this about the `grub_bash_' prefix.  I think it is a bit confusing
>because the syntax is bash like, it is not bash.  I would prefer a
>grub_script_ or grub_scripting_ prefix.
>
>  
>
As you want. Anyway it's easy to change by simple replacing and it has 
no importance for me

>>>- What is that huge table with operators?
>>>
>>>      
>>>
>>It's used to determinate which operator to execute (see
>>grub_bash_find_oper and grub_bash_eval_arith)
>>    
>>
>
>Ok.
>
>  
>
>>>What kind of parser is it?
>>>
>>>
>>>      
>>>
>>It's a direct parser with aritmetic subparser. Main parser is
>>grub_bash_execute, arithmetic subparser is grub_bash_eval_arith.
>>grub_bash_execute determinates the special cases (loops,conditions,
>>functions,...) for other cases (commands,assignments, function calling)
>>it calls grub_bash_split_tokens, grub_bash_expand_braces and
>>grub_bash_expand_dollar
>>
>>    
>>
>>> I have never seen this in a top-down or bottom-up parser I have
>>> studied.
>>>      
>>>
>>I don't like to write the things reffering every time to algorithm.
>>Genereally I take some ideas and I write myself, at my own.
>>    
>>
>
>What do you mean?
>
>The problem is that I like proven concepts.  And when you use a
>commonly known parser design many people will be able to understand
>it.  To me this is REALLY important.  I wonder what other developers
>think of that.
>
>  
>
I use proven concepts as base but then I adapt them

>>>So can you explain what
>>> happens when executing a script?  First you load the file.  Do you
>>> parse it, make pcode of it, run it directly?
>>>
>>>      
>>>
>>For the files I use grub_bash_exec_file. Only thing it does is
>>reading a file line by line and calling grub_bash_execute
>>    
>>
>
>So you run it while parsing, ok.
>
>  
>
>>> How about error
>>> handling?
>>>
>>>      
>>>
>>For now the problem is that not all posiible syntax errors are handled
>>correctly and more return checks have to be written. But first I'll write
>>line counting (only grub_bash_execute, grub_bash_list_execute and
>>grub_command_execute are affected)
>>    
>>
>
>Ok.  Error handling is often not implemented in small parsers because
>it can be really hard.  Don't forget error handling is really
>important.  Syntax errors should not make the parser crash, hang,
>etc.  Producing the right error and handling it right so GRUB remains
>in a valid state, etc is a difficult task, I think.
>
>  
>
Not with bash because in many constructions (except loops,
conditions and arithmetic) when some structure is not valid
it just lefts it unchanged (consider like a string or a command)

>Thanks,
>Marco
>
>
>
>_______________________________________________
>Grub-devel mailing list
>Grub-devel@gnu.org
>http://lists.gnu.org/mailman/listinfo/grub-devel
>
>
>  
>

Re: Scripting

[Hollis Blanchard]

On Feb 13, 2005, at 12:56 PM, Marco Gerards wrote:

> Serbinenko Vladimir <serbinenko.vova@list.ru> writes:
>>> What kind of parser is it?
>>>
>> It's a direct parser with aritmetic subparser. Main parser is
>> grub_bash_execute, arithmetic subparser is grub_bash_eval_arith.
>> grub_bash_execute determinates the special cases (loops,conditions,
>> functions,...) for other cases (commands,assignments, function 
>> calling)
>> it calls grub_bash_split_tokens, grub_bash_expand_braces and
>> grub_bash_expand_dollar
>>
>>>  I have never seen this in a top-down or bottom-up parser I have
>>>  studied.
>> I don't like to write the things reffering every time to algorithm.
>> Genereally I take some ideas and I write myself, at my own.
>
> What do you mean?
>
> The problem is that I like proven concepts.  And when you use a
> commonly known parser design many people will be able to understand
> it.  To me this is REALLY important.  I wonder what other developers
> think of that.

I agree. Hand-written parsers are very hairy to implement, with nasty 
bugs and corner cases. Although I haven't studied the theory, I know 
that there are traditional parsing/lexing/whatever techniques that are 
well-understood.

In fact, there's a whole bunch of tools like flex and bison that we 
could use to avoid hand-written errors. Why don't we use those?

-Hollis

Re: Scripting

[Marco Gerards]

Hollis Blanchard <hollis@penguinppc.org> writes:

> On Feb 13, 2005, at 12:56 PM, Marco Gerards wrote:
>
>> Serbinenko Vladimir <serbinenko.vova@list.ru> writes:
>>>> What kind of parser is it?
>>>>
>>> It's a direct parser with aritmetic subparser. Main parser is
>>> grub_bash_execute, arithmetic subparser is grub_bash_eval_arith.
>>> grub_bash_execute determinates the special cases (loops,conditions,
>>> functions,...) for other cases (commands,assignments, function
>>> calling)
>>> it calls grub_bash_split_tokens, grub_bash_expand_braces and
>>> grub_bash_expand_dollar
>>>
>>>>  I have never seen this in a top-down or bottom-up parser I have
>>>>  studied.
>>> I don't like to write the things reffering every time to algorithm.
>>> Genereally I take some ideas and I write myself, at my own.
>>
>> What do you mean?
>>
>> The problem is that I like proven concepts.  And when you use a
>> commonly known parser design many people will be able to understand
>> it.  To me this is REALLY important.  I wonder what other developers
>> think of that.
>
> I agree. Hand-written parsers are very hairy to implement, with nasty
> bugs and corner cases. Although I haven't studied the theory, I know
> that there are traditional parsing/lexing/whatever techniques that are
> well-understood.

Right.  But I would not have a problem with a hand written parser, as
long as I can understand it. :)

> In fact, there's a whole bunch of tools like flex and bison that we
> could use to avoid hand-written errors. Why don't we use those?

One thing that should be looked into before using flex and bison is
how much the binary will grow.  Another thing is how to integrate it
with the command line.

Thanks,
Marco

Re: Scripting

[Serbinenko Vladimir]

Marco Gerards wrote:

>Hollis Blanchard <hollis@penguinppc.org> writes:
>
>  
>
>>On Feb 13, 2005, at 12:56 PM, Marco Gerards wrote:
>>
>>    
>>
>>>Serbinenko Vladimir <serbinenko.vova@list.ru> writes:
>>>      
>>>
>>>>>What kind of parser is it?
>>>>>
>>>>>          
>>>>>
>>>>It's a direct parser with aritmetic subparser. Main parser is
>>>>grub_bash_execute, arithmetic subparser is grub_bash_eval_arith.
>>>>grub_bash_execute determinates the special cases (loops,conditions,
>>>>functions,...) for other cases (commands,assignments, function
>>>>calling)
>>>>it calls grub_bash_split_tokens, grub_bash_expand_braces and
>>>>grub_bash_expand_dollar
>>>>
>>>>        
>>>>
>>>>> I have never seen this in a top-down or bottom-up parser I have
>>>>> studied.
>>>>>          
>>>>>
>>>>I don't like to write the things reffering every time to algorithm.
>>>>Genereally I take some ideas and I write myself, at my own.
>>>>        
>>>>
>>>What do you mean?
>>>
>>>The problem is that I like proven concepts.  And when you use a
>>>commonly known parser design many people will be able to understand
>>>it.  To me this is REALLY important.  I wonder what other developers
>>>think of that.
>>>      
>>>
>>I agree. Hand-written parsers are very hairy to implement, with nasty
>>bugs and corner cases. Although I haven't studied the theory, I know
>>that there are traditional parsing/lexing/whatever techniques that are
>>well-understood.
>>    
>>
>
>Right.  But I would not have a problem with a hand written parser, as
>long as I can understand it. :)
>
>  
>
>>In fact, there's a whole bunch of tools like flex and bison that we
>>could use to avoid hand-written errors. Why don't we use those?
>>    
>>
>
>One thing that should be looked into before using flex and bison is
>how much the binary will grow.  
>
I think less than with hand-writing parser because of its structure

>Another thing is how to integrate it
>with the command line.
>
>  
>
I know how to write it and if you have no objection I'll do it.

>Thanks,
>Marco
>
>
>
>_______________________________________________
>Grub-devel mailing list
>Grub-devel@gnu.org
>http://lists.gnu.org/mailman/listinfo/grub-devel
>
>
>  
>

Re: Scripting

[Yoshinori K. Okuji]

On Tuesday 15 February 2005 17:16, Serbinenko Vladimir wrote:
> >One thing that should be looked into before using flex and bison is
> >how much the binary will grow.
>
> I think less than with hand-writing parser because of its structure

I like a hand-written parser as long as it is clean. flex and bison are 
difficult to use in GRUB, because they emit source code which include 
many header files.

Okuji