Ideas for the future

Ideas for the future

[Andreas Vogel]

I took the last few nights to divide my previously submitted huge patch
into logical parts (around 10 patches now). Some of them I've submitted
already.

So right now it seems to me that it's useless to waste your time (and my
time too) to submit more patches or even to discuss them due to code
freeze and because all time is needed now to prepare release 2.0.

Even though I fully understand this situation it's really sad that some
of the most wanted features for GRUB will still not be available in the
upcoming release (especially the possibility to have a settings menu).
Personally i can live with that coz I'm using my private patches for my
projects which do need those features.

Anyway, I don't want that those ideas are lost so let me summarize the
enhancements I have patches for and what i think would be great to have
in the future:

1) Environment variable substitution in menus. For normal menu entries
this works already. For submenus this doesn't work as the submenu
entries are not re-evaluated after execution of it's menuentries.
Example:
    set lang=us
    menuentry 'Boot with lang=$lang' { ... ; linux lang=$lang ; boot }
    submenu Settings {
        submenu 'Language... (current lang = $lang)' {
            menuentry --silent=1 'Set lang US'  { set lang=us }
            menuentry --silent=1 'Set lang DE'  { set lang=de }
        }
    }

2) Environment variable substitutions in theme labels. Theme labels
should be able to reference environment variables for display. It
would/could be even great to use environment variables for different
things in themes (fonts, pictures, etc...). By this it would be possible
to use a quite generic theme.txt file for different resolutions, etc.

3) Enhanced hotkey handling: support ALT, SHIFT and CTRL modifiers.

4) menuentry/submenu --hidden 0|1
Hidden menuentries behave the same like normal menu entries but they are
not visible on the screen. They can only be activated using a hotkey. By
this you can define a help screen using hotkey F1 but no visible menu
entry is needed.

5) menuentry --silent 0|1
When using menuentries which just sets some variables or do some other
(non booting tasks), it's really bothering to see a flickering empty
terminal box just for nothing. When this flag is set, the terminal box
will not be shown by default when the entry is executed. Execution of
submenus should be always silent.

6) menuentry --enabled 0|1
It's a good practice to show menuentries even if they are not applicable
in different situations (that's common for all major menu systems). If a
menu entry is disabled, it is shown but it is not operable. E.g. one
might have a general grub config file which supports booting a bunch of
ISO images. When an ISO image is not found and instead of not showing a
menuentry for that, those menuentry could be shown as disabled.

As I said before, I have patches which implements all those features and
I'm using these features in projects right now.

Vladimir, it seems that GRUB is a one man show and it's really your
baby. Don't get me wrong please, I really appreciate your hard work and
from our conversation I can feel that you're really a genius. Whenever
you have time again for new ideas, new patches and new discussions, let
me know. It's just the wrong time right now for that.

Andreas

Re: Ideas for the future

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 05.03.2012 02:13, Andreas Vogel wrote:
> I took the last few nights to divide my previously submitted huge patch
> into logical parts (around 10 patches now). Some of them I've submitted
> already.
>
> So right now it seems to me that it's useless to waste your time (and my
> time too) to submit more patches or even to discuss them due to code
> freeze and because all time is needed now to prepare release 2.0.
>
> Even though I fully understand this situation it's really sad that some
> of the most wanted features for GRUB will still not be available in the
> upcoming release (especially the possibility to have a settings menu).
> Personally i can live with that coz I'm using my private patches for my
> projects which do need those features.
>
> Anyway, I don't want that those ideas are lost so let me summarize the
> enhancements I have patches for and what i think would be great to have
> in the future:
>
> 1) Environment variable substitution in menus. For normal menu entries
> this works already. For submenus this doesn't work as the submenu
> entries are not re-evaluated after execution of it's menuentries.
> Example:
>      set lang=us
>      menuentry 'Boot with lang=$lang' { ... ; linux lang=$lang ; boot }
>      submenu Settings {
>          submenu 'Language... (current lang = $lang)' {
>              menuentry --silent=1 'Set lang US'  { set lang=us }
>              menuentry --silent=1 'Set lang DE'  { set lang=de }
>          }
>      }
Have you seen the argument possibility?
> 2) Environment variable substitutions in theme labels. Theme labels
> should be able to reference environment variables for display. It
> would/could be even great to use environment variables for different
> things in themes (fonts, pictures, etc...).
That seems pretty vague do you have an idea in mind?
>   By this it would be possible
> to use a quite generic theme.txt file for different resolutions, etc.
This is already possible. Use percent notation for desired size and 
rendering will figure out the actual size basing on constraints.
> 3) Enhanced hotkey handling: support ALT, SHIFT and CTRL modifiers.
>
> 4) menuentry/submenu --hidden 0|1
We don't use 0|1. We just make it argumentless and option toggles the 
behaviour
> Hidden menuentries behave the same like normal menu entries but they are
> not visible on the screen. They can only be activated using a hotkey. By
> this you can define a help screen using hotkey F1 but no visible menu
> entry is needed.
The problem is that such entries are not usable if the hotkey in 
question is unavailable because of terminal limitations.
> 5) menuentry --silent 0|1
> When using menuentries which just sets some variables or do some other
> (non booting tasks), it's really bothering to see a flickering empty
> terminal box just for nothing. When this flag is set, the terminal box
> will not be shown by default when the entry is executed. Execution of
> submenus should be always silent.
Rather than removing messages better move them to some status bar in the 
theme.
> 6) menuentry --enabled 0|1
> It's a good practice to show menuentries even if they are not applicable
> in different situations (that's common for all major menu systems). If a
> menu entry is disabled, it is shown but it is not operable. E.g. one
> might have a general grub config file which supports booting a bunch of
> ISO images. When an ISO image is not found and instead of not showing a
> menuentry for that, those menuentry could be shown as disabled.
This seems like just cluttering the view. Remember that in some 
applications (e.g. braille) menu has to be very concise. We support even 
the tiny (40x1) terminal geometries.
> As I said before, I have patches which implements all those features and
> I'm using these features in projects right now.
>
> Vladimir, it seems that GRUB is a one man show
Some of the times it is, sometimes there are more active devs around. 
It's somewhat periodic.
>   and it's really your
> baby. Don't get me wrong please, I really appreciate your hard work and
> from our conversation I can feel that you're really a genius. Whenever
> you have time again for new ideas, new patches and new discussions, let
> me know. It's just the wrong time right now for that.
>
> Andreas
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko

Re: Ideas for the future

[Samuel Thibault]

Vladimir 'φ-coder/phcoder' Serbinenko, le Mon 05 Mar 2012 02:30:11 +0100, a écrit :
> >6) menuentry --enabled 0|1
> >It's a good practice to show menuentries even if they are not applicable
> >in different situations (that's common for all major menu systems). If a
> >menu entry is disabled, it is shown but it is not operable. E.g. one
> >might have a general grub config file which supports booting a bunch of
> >ISO images. When an ISO image is not found and instead of not showing a
> >menuentry for that, those menuentry could be shown as disabled.
> This seems like just cluttering the view. Remember that in some applications
> (e.g. braille) menu has to be very concise. We support even the tiny (40x1)
> terminal geometries.

Actually, 40x1 is relatively large for a braille device. A lot of them
are 20x1.

Samuel

Re: Ideas for the future

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 05.03.2012 02:35, Samuel Thibault wrote:
> Vladimir 'φ-coder/phcoder' Serbinenko, le Mon 05 Mar 2012 02:30:11 +0100, a écrit :
>>> 6) menuentry --enabled 0|1
>>> It's a good practice to show menuentries even if they are not applicable
>>> in different situations (that's common for all major menu systems). If a
>>> menu entry is disabled, it is shown but it is not operable. E.g. one
>>> might have a general grub config file which supports booting a bunch of
>>> ISO images. When an ISO image is not found and instead of not showing a
>>> menuentry for that, those menuentry could be shown as disabled.
>> This seems like just cluttering the view. Remember that in some applications
>> (e.g. braille) menu has to be very concise. We support even the tiny (40x1)
>> terminal geometries.
> Actually, 40x1 is relatively large for a braille device. A lot of them
> are 20x1.
20x1 works as well. The bare minimum is 5x1 (we need 4 positions to 
indicate that there are more entries or more chars in the entry).
For less than 20x1  4 special positions become wasteful and the code 
should probably check those explicitly.
Is less than 20x1 common?
> Samuel
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko

Re: Ideas for the future

[Samuel Thibault]

Vladimir 'φ-coder/phcoder' Serbinenko, le Mon 05 Mar 2012 02:40:57 +0100, a écrit :
> On 05.03.2012 02:35, Samuel Thibault wrote:
> >Vladimir 'φ-coder/phcoder' Serbinenko, le Mon 05 Mar 2012 02:30:11 +0100, a écrit :
> >>>6) menuentry --enabled 0|1
> >>>It's a good practice to show menuentries even if they are not applicable
> >>>in different situations (that's common for all major menu systems). If a
> >>>menu entry is disabled, it is shown but it is not operable. E.g. one
> >>>might have a general grub config file which supports booting a bunch of
> >>>ISO images. When an ISO image is not found and instead of not showing a
> >>>menuentry for that, those menuentry could be shown as disabled.
> >>This seems like just cluttering the view. Remember that in some applications
> >>(e.g. braille) menu has to be very concise. We support even the tiny (40x1)
> >>terminal geometries.
> >Actually, 40x1 is relatively large for a braille device. A lot of them
> >are 20x1.
> 20x1 works as well. The bare minimum is 5x1 (we need 4 positions to indicate
> that there are more entries or more chars in the entry).
> For less than 20x1  4 special positions become wasteful and the code should
> probably check those explicitly.
> Is less than 20x1 common?

No.

Samuel

Re: Ideas for the future

[Andreas Vogel]

Am 05.03.2012 02:30, schrieb Vladimir 'φ-coder/phcoder' Serbinenko:
>> this works already. For submenus this doesn't work as the submenu
>> entries are not re-evaluated after execution of it's menuentries.
>> Example:
>>      set lang=us
>>      menuentry 'Boot with lang=$lang' { ... ; linux lang=$lang ; boot }
>>      submenu Settings {
>>          submenu 'Language... (current lang = $lang)' {
>>              menuentry --silent=1 'Set lang US'  { set lang=us }
>>              menuentry --silent=1 'Set lang DE'  { set lang=de }
>>          }
>>      }
> 1) Environment variable substitution in menus. For normal menu entries
> Have you seen the argument possibility?
Yes, I know about it. But that doesn't help because the submenu
definition is read only once, so after that initial read the title is
and remains static text.


>> 2) Environment variable substitutions in theme labels. Theme labels
>> should be able to reference environment variables for display. It
>> would/could be even great to use environment variables for different
>> things in themes (fonts, pictures, etc...).
> That seems pretty vague do you have an idea in mind?
Sure. I wanna be able to display labels in the theme which shows the
current language, keyboard and other parameters which are used to boot
the linux kernel and which can be set in the settings submenu. All those
settings are environment variables, but right now there is no way to use
them in themes.


>>   By this it would be possible
>> to use a quite generic theme.txt file for different resolutions, etc.
> This is already possible. Use percent notation for desired size and
> rendering will figure out the actual size basing on constraints.
I know about that, but that's not the point.
I have smth in mind like:

set myfont="Fixed Regular 10"
if [ "$gfxmode" = "800x600" ] ; then set myfont="Fixed Regular 12" ; fi
if [ "$gfxmode" = "1280x1024" ] ; then set myfont="Fixed Regular 14" ; fi

and in the theme

+ boot_menu {
    item_font = "$myfont"
}

This is just an example. We could use it for almost everything in the
theme: background pictures, colors, fonts, text, etc. E.g., why do i
need to have 2 different theme.txt files when i just wanna have a
different desktop image?

BTW, another point which might be addressed in the future: the global
theme properties like "desktop-image" or "title-text" use minus char
between words, all other properties are using underline. Not really
consistent.


>
>> 3) Enhanced hotkey handling: support ALT, SHIFT and CTRL modifiers.
>>
>> 4) menuentry/submenu --hidden 0|1
> We don't use 0|1. We just make it argumentless and option toggles the
> behaviour
I know. But there is a slight advantage using a boolean argument for
such commands: it's a little nicer to deal with them when using variables.
E.g.:

    if [ "feature" = unavail ] ; then
        set hidden=1
    else
        set hidden=0
    fi
    menuentry "Boot memtest86" --hidden $hidden { ... }

for looks nicer opposed to

    if [ "feature" = unavail ] ; then
        set hidden="--hidden"
    else
        set hidden=
    fi
    menuentry "Boot memtest86" $hidden { ... }

When i implemented my patches, i wanted to use both ways: a command line
option with an optional argument. By this we would have had what you
preference and my way too. Regarding optional arguments the option
handling in GRUB is actually broken by design, so this is,
unfortunately, not an option.

The reason for why i say that optional argument parsing is broken by
design is because of that:
Let's assume the menuentry command.
When I define an additional option -s | --silent taking an optional
integer argument, then calling

    menuentry title --silent { echo OK }

gives an error "--silent requires an integer". This is because the
option parsing code handles the "{ ... }" as the value to the option
--silent.
The only way to prevent this (not acceptable IMO) is to call

    menuentry title --silent -- { echo OK }


>> Hidden menuentries behave the same like normal menu entries but they are
>> not visible on the screen. They can only be activated using a hotkey. By
>> this you can define a help screen using hotkey F1 but no visible menu
>> entry is needed.
> The problem is that such entries are not usable if the hotkey in
> question is unavailable because of terminal limitations.
Don't really understand your argument. Of course you'll have problems if
you use a key which is not available on your keyboard. For my example
implementing a help screen which is shown by pressing F1 you can use
another hotkey, e.g. <CTRL>-h.
I don't really see the point against having hidden menuentries,
especially when taking into account that i provided a real life example.


>> 5) menuentry --silent 0|1
>> When using menuentries which just sets some variables or do some other
>> (non booting tasks), it's really bothering to see a flickering empty
>> terminal box just for nothing. When this flag is set, the terminal box
>> will not be shown by default when the entry is executed. Execution of
>> submenus should be always silent.
> Rather than removing messages better move them to some status bar in
> the theme.
You didn't get the point. Why should any terminal box open when there is
nothing to display? When there are errors, the terminal box will open
anyway.
What bothers me (and btw. a quite some others) is that when you have
such a menu entry
    menuentry 'Set language to US' { set lang=us }
and when executing this entry an empty terminal box will be shown for a
very short time (opened and closed). It's just flickering, totally
useless and bothering, not nice.


>> 6) menuentry --enabled 0|1
>> It's a good practice to show menuentries even if they are not applicable
>> in different situations (that's common for all major menu systems). If a
>> menu entry is disabled, it is shown but it is not operable. E.g. one
>> might have a general grub config file which supports booting a bunch of
>> ISO images. When an ISO image is not found and instead of not showing a
>> menuentry for that, those menuentry could be shown as disabled.
> This seems like just cluttering the view. Remember that in some
> applications (e.g. braille) menu has to be very concise. We support
> even the tiny (40x1) terminal geometries.
Not at all. Every decent menu system supports disabled menu entries and
serious design guides suggest better to have disabled menu entries than
not to show them at all. If you have a look in Firefox, Thunderbird
(just to mention 2 programs), you'll see  that they all use disabled
menu entries.
Btw, I don't really understand your point about braille displays: a
disabled menu entry would look almost the same like an enabled one.


Andreas

Re: Ideas for the future

[Vladimir 'φ-coder/phcoder' Serbinenko]

(CC'ing Colin because of theme stuff and it overlaps with what he needs 
for Ubuntu)
>>>    By this it would be possible
>>> to use a quite generic theme.txt file for different resolutions, etc.
>> This is already possible. Use percent notation for desired size and
>>
>> BTW, another point which might be addressed in the future: the global
>> theme properties like "desktop-image" or "title-text" use minus char
>> between words, all other properties are using underline. Not really
>> consistent.
That's unfortunate that noone noticed it when it was comitted but now 
we're stuck with it (compatibility)
>
>>> 3) Enhanced hotkey handling: support ALT, SHIFT and CTRL modifiers.
>>>
>>> 4) menuentry/submenu --hidden 0|1
>> We don't use 0|1. We just make it argumentless and option toggles the
>> behaviour
> I know. But there is a slight advantage using a boolean argument for
> such commands: it's a little nicer to deal with them when using variables.
> E.g.:
>
>      if [ "feature" = unavail ] ; then
>          set hidden=1
>      else
>          set hidden=0
>      fi
>      menuentry "Boot memtest86" --hidden $hidden { ... }
>
> for looks nicer opposed to
>
>      if [ "feature" = unavail ] ; then
>          set hidden="--hidden"
>      else
>          set hidden=
>      fi
>      menuentry "Boot memtest86" $hidden { ... }
I understand your point but consistency is more important.
> When i implemented my patches, i wanted to use both ways: a command line
> option with an optional argument. By this we would have had what you
> preference and my way too. Regarding optional arguments the option
> handling in GRUB is actually broken by design, so this is,
> unfortunately, not an option.
Again it's unfortunate that noone noticed it when it was committed and 
now we're stuck with it.

> Don't really understand your argument. Of course you'll have problems if
> you use a key which is not available on your keyboard. For my example
> implementing a help screen which is shown by pressing F1 you can use
> another hotkey, e.g.<CTRL>-h.
> I don't really see the point against having hidden menuentries,
> especially when taking into account that i provided a real life example.
If the option isn't hidden the unsupported hotkey is only a minor 
problem since you can still select the entry explicitly.
As a compromise it may be possible to make it hidden only on gfxmenu 
while keeping it fully visible on normal menu renderer.
>
>>> 5) menuentry --silent 0|1
>>> When using menuentries which just sets some variables or do some other
>>> (non booting tasks), it's really bothering to see a flickering empty
>>> terminal box just for nothing. When this flag is set, the terminal box
>>> will not be shown by default when the entry is executed. Execution of
>>> submenus should be always silent.
>> Rather than removing messages better move them to some status bar in
>> the theme.
> You didn't get the point. Why should any terminal box open when there is
> nothing to display?
I think you don't get mine: if this message goes to status bar it 
doesn't go to the terminal and so it doesn't open.


> Not at all. Every decent menu system supports disabled menu entries and
> serious design guides suggest better to have disabled menu entries than
> not to show them at all. If you have a look in Firefox, Thunderbird
> (just to mention 2 programs), you'll see  that they all use disabled
> menu entries.
> Btw, I don't really understand your point about braille displays: a
> disabled menu entry would look almost the same like an enabled one.
Try living a day on 20x1 terminal and tell me what you think about all 
extra useless info you get.


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko

Re: Ideas for the future

[Andreas Vogel]

Am 05.03.2012 13:54, schrieb Vladimir 'φ-coder/phcoder' Serbinenko:
>> option with an optional argument. By this we would have had what you
>> preference and my way too. Regarding optional arguments the option
>> handling in GRUB is actually broken by design, so this is,
>> unfortunately, not an option.
> When i implemented my patches, i wanted to use both ways: a command line
> Again it's unfortunate that noone noticed it when it was committed and
> now we're stuck with it.

You should think about that again. GRUB is broken regarding that and it
should be fixed anyway. Right now it seems that there is only one
command which uses GRUB_ARG_OPTION_OPTIONAL so maybe it's one of the
last chances to have a cheap fix.

The (only!?) place where an optional option is used is the --set option
for the search command.

The manual entry for search states:

     search [--file|--label|--fs-uuid] [--set [var]] [--no-floppy] name

The description is wrong. For --set it's only possible to omit "var" iff
another option is following the --set option.

    OK: search  --file  --set  --nofloppy  /boot/grub/grub.cfg
    OK: search  --file  --set  --  /boot/grub/grub.cfg
    ERROR: search  --file  --set  /boot/grub/grub.cfg

It's either needed to correct the manual or to fix the code.

If it's decided that the code cannot be fixed (for whatever reasons) the
use of optional option arguments should be strongly discouraged or even
forbidden then.

Andreas

Re: Ideas for the future

[Andreas Vogel]

Am 05.03.2012 13:54, schrieb Vladimir 'φ-coder/phcoder' Serbinenko:
>>>> 5) menuentry --silent 0|1
>>>> When using menuentries which just sets some variables or do some other
>>>> (non booting tasks), it's really bothering to see a flickering empty
>>>> terminal box just for nothing. When this flag is set, the terminal box
>>>> will not be shown by default when the entry is executed. Execution of
>>>> submenus should be always silent.
>>> Rather than removing messages better move them to some status bar in
>>> the theme.
>> You didn't get the point. Why should any terminal box open when there is
>> nothing to display?
> I think you don't get mine: if this message goes to status bar it
> doesn't go to the terminal and so it doesn't open. 

There are *no* messages at all when executing such entries. No need for
any terminal box or status bar. No messages are removed or need to be
directed to anywhere, because there are no messages, not even one single
character of output. A menuentry flagged as --silent will not produce
any output, never ever. It might produce errors and in this case the
terminal box is opened and the error is shown as it is the case in the
current version.

Anyway, I tried to check out your proposal at least... where can i find
the code handling a status bar?

Andreas

[BUG] GRUBs option parsing needs fixing

[Andreas Vogel]

Hi all,

I start a new thread with this mail in order to have a thread on its own
for this subject.

In another thread we've already had some discussion about GRUBs option
parsing. I wanna summarize and describe here about the issue.

Right now I see 2 problems with GRUBs argument parsing:

1) GRUBs argument parsing is not POSIX compliant.

Problem:
POSIX (and GNU too) recommends (see
http://www.gnu.org/software/libc/manual/html_node/Argument-Syntax.html):

"An option and its argument may or may not appear as separate tokens.
(In other words, the whitespace separating them is optional.) Thus, ‘-o
foo’ and ‘-ofoo’ are equivalent."

This is doesn't hold for GRUB.
When I try
    load_env -fenv
an error message
    error: unknown argument '-e'.
is returned.

Solution:
The GRUB argument parser needs to be fixed so that short options are
parsed according to POSIX/GNU standards.

2) Optional option argument is not handled correctly (and not according
to POSIX/GNU standard)

Problem:
Right now the GRUB argument parser doesn't handle optional arguments
properly and it doesn't comply to POSIX/GNU standards.

For short options parsing fails for the reason described above and
because the parser allows that the option and its (optional) argument
might be separated with whitespace.

For long options parsing fails too because the parser allows that the
option and its (optional) argument might be separated with whitespace.
Example:
    OK: search  --file  --set  --nofloppy  /boot/grub/grub.cfg
    OK: search  --file  --set  --  /boot/grub/grub.cfg
    ERROR: search  --file  --set  /boot/grub/grub.cfg

Solution:
This solution follows just the POSIX/GNU standards for argument syntax
as stated in the above mentioned HTML document.
In order to be able to handle optional arguments for options the GRUB
argument parser needs to implement parsing according to the following
syntax:

a) Short option: e.g. option name 'x' taking an optional argument '<arg>'
     Possible options: "-x"   or   "-x<arg>"

b) Long option: e.g. option name 'xlong' taking an optional argument '<arg>'
     Possible options: "--xlong"   or   "--xlong=<arg>"  or  "--xlong="
     For the third form the upcoming implementation is somehow free to
decide how to interpret that option. Regarding to GNUs getopt() man
page, this form will be interpreted by getopt() as if the option isn't
specified at all (due to a bug). Because that interpretation is based on
a bug and because it might make more sense the third form could/should
be interpreted as if "--xlong" has been specified (meaning: options is
present but without value).

So for both, short and long options taking an optional value, no
whitespace between option and its value (if the value is present) is
allowed.

IMHO the option parsing code in GRUB2 should be fixed as soon as
possible. The later it will be done the more we'll have to fight with
compatibility issues.

Any comments?

Andreas

Re: Ideas for the future

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 05.03.2012 16:43, Andreas Vogel wrote:
> Am 05.03.2012 13:54, schrieb Vladimir 'φ-coder/phcoder' Serbinenko:
>>> option with an optional argument. By this we would have had what you
>>> preference and my way too. Regarding optional arguments the option
>>> handling in GRUB is actually broken by design, so this is,
>>> unfortunately, not an option.
>> When i implemented my patches, i wanted to use both ways: a command line
>> Again it's unfortunate that noone noticed it when it was committed and
>> now we're stuck with it.
> You should think about that again. GRUB is broken regarding that and it
> should be fixed anyway. Right now it seems that there is only one
> command which uses GRUB_ARG_OPTION_OPTIONAL so maybe it's one of the
> last chances to have a cheap fix.
Learn to use rgrep before making unsupported, easy to check claims:
./grub-core/commands/search_wrap.c:    {"set",        's', 
GRUB_ARG_OPTION_OPTIONAL,
./grub-core/loader/i386/bsd.c:    {"serial", 'h', GRUB_ARG_OPTION_OPTIONAL,
./grub-core/loader/i386/bsd.c:    {"serial", 'h', GRUB_ARG_OPTION_OPTIONAL,
>


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko

Re: [BUG] GRUBs option parsing needs fixing

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 08.03.2012 14:12, Andreas Vogel wrote:
> Hi all,
>
> I start a new thread with this mail in order to have a thread on its own
> for this subject.
Please don't CC Colin Watson (or me for that matter) for everything, 
it's bad tone.
> In another thread we've already had some discussion about GRUBs option
> parsing. I wanna summarize and describe here about the issue.
>
> Right now I see 2 problems with GRUBs argument parsing:
>
> 1) GRUBs argument parsing is not POSIX compliant.
We don't follow POSIX.
>
> 2) Optional option argument is not handled correctly (and not according
> to POSIX/GNU standard)
Well it's possible to do something like

=== modified file 'grub-core/lib/arg.c'
--- grub-core/lib/arg.c    2012-02-08 18:26:01 +0000
+++ grub-core/lib/arg.c    2012-03-08 14:13:21 +0000
@@ -294,7 +291,8 @@
          }
            else
          {
-          if (opt->type != ARG_TYPE_NONE)
+          if (opt->type != ARG_TYPE_NONE
+ && !(opt->flags & GRUB_ARG_OPTION_OPTIONAL))
              {
                if (curarg + 1 < argc)
              {
@@ -333,7 +331,8 @@
        opt = find_long (cmd->options, arg + 2, arglen);

        if (!option && argv[curarg + 1] && argv[curarg + 1][0] != '-'
- && opt && opt->type != ARG_TYPE_NONE)
+ && opt && opt->type != ARG_TYPE_NONE
+ && !(opt->flags & GRUB_ARG_OPTION_OPTIONAL))
          option = argv[++curarg];

        if (!opt && (cmd->cmd->flags & GRUB_COMMAND_ACCEPT_DASH))

But it would break configurations like -h com0 or -s root.

-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko

Re: Ideas for the future

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 05.03.2012 12:16, Andreas Vogel wrote:
>      if [ "feature" = unavail ] ; then
>          set hidden=1
>      else
>          set hidden=0
>      fi
>      menuentry "Boot memtest86" --hidden $hidden { ... }
>
> for looks nicer opposed to
>
>      if [ "feature" = unavail ] ; then
>          set hidden="--hidden"
>      else
>          set hidden=
>      fi
>      menuentry "Boot memtest86" $hidden { ... }
It's a question of personal preference and I personally prefer the 
second one. And even if behaviour of optional arguments is changed it 
doesn't mean that we should increase bitrot by having different 
interface conventions for some options.

-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko

Re: [BUG] GRUBs option parsing needs fixing

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 08.03.2012 15:15, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> On 08.03.2012 14:12, Andreas Vogel wrote:
>> Hi all,
>>
>> I start a new thread with this mail in order to have a thread on its own
>> for this subject.
> Please don't CC Colin Watson (or me for that matter) for everything, 
> it's bad tone.
>> In another thread we've already had some discussion about GRUBs option
>> parsing. I wanna summarize and describe here about the issue.
>>
>> Right now I see 2 problems with GRUBs argument parsing:
>>
>> 1) GRUBs argument parsing is not POSIX compliant.
> We don't follow POSIX.
>>
>> 2) Optional option argument is not handled correctly (and not according
>> to POSIX/GNU standard)
> Well it's possible to do something like
>
> === modified file 'grub-core/lib/arg.c'
> --- grub-core/lib/arg.c    2012-02-08 18:26:01 +0000
> +++ grub-core/lib/arg.c    2012-03-08 14:13:21 +0000
> @@ -294,7 +291,8 @@
>          }
>            else
>          {
> -          if (opt->type != ARG_TYPE_NONE)
> +          if (opt->type != ARG_TYPE_NONE
> + && !(opt->flags & GRUB_ARG_OPTION_OPTIONAL))
>              {
>                if (curarg + 1 < argc)
>              {
> @@ -333,7 +331,8 @@
>        opt = find_long (cmd->options, arg + 2, arglen);
>
>        if (!option && argv[curarg + 1] && argv[curarg + 1][0] != '-'
> - && opt && opt->type != ARG_TYPE_NONE)
> + && opt && opt->type != ARG_TYPE_NONE
> + && !(opt->flags & GRUB_ARG_OPTION_OPTIONAL))
>          option = argv[++curarg];
>
>        if (!opt && (cmd->cmd->flags & GRUB_COMMAND_ACCEPT_DASH))
>
> But it would break configurations like -h com0 or -s root.
>
A possible compromise would be to change the behaviour of long options only.

-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko

Re: [BUG] GRUBs option parsing needs fixing

[Andreas Vogel]

Am 08.03.2012 15:32, schrieb Vladimir 'φ-coder/phcoder' Serbinenko:
> On 08.03.2012 15:15, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>> On 08.03.2012 14:12, Andreas Vogel wrote:
>>> Hi all,
>>>
>>> I start a new thread with this mail in order to have a thread on its
>>> own
>>> for this subject.
>> Please don't CC Colin Watson (or me for that matter) for everything,
>> it's bad tone.
I just used Reply-All in my mail program, so please excuse me and I
really hope that i didn't offend anyone, it was not by purpose.

>>> In another thread we've already had some discussion about GRUBs option
>>> parsing. I wanna summarize and describe here about the issue.
>>>
>>> Right now I see 2 problems with GRUBs argument parsing:
>>>
>>> 1) GRUBs argument parsing is not POSIX compliant.
>> We don't follow POSIX.
But you were telling that you follow GNU, right? And regarding this
subject GNU follows POSIX, qed.

Re: Ideas for the future

[Andreas Vogel]

Am 08.03.2012 15:11, schrieb Vladimir 'φ-coder/phcoder' Serbinenko:
> On 05.03.2012 16:43, Andreas Vogel wrote:
>> Am 05.03.2012 13:54, schrieb Vladimir 'φ-coder/phcoder' Serbinenko:
>>>> option with an optional argument. By this we would have had what you
>>>> preference and my way too. Regarding optional arguments the option
>>>> handling in GRUB is actually broken by design, so this is,
>>>> unfortunately, not an option.
>>> When i implemented my patches, i wanted to use both ways: a command
>>> line
>>> Again it's unfortunate that noone noticed it when it was committed and
>>> now we're stuck with it.
>> You should think about that again. GRUB is broken regarding that and it
>> should be fixed anyway. Right now it seems that there is only one
>> command which uses GRUB_ARG_OPTION_OPTIONAL so maybe it's one of the
>> last chances to have a cheap fix.
> Learn to use rgrep before making unsupported, easy to check claims:
> ./grub-core/commands/search_wrap.c:    {"set",        's',
> GRUB_ARG_OPTION_OPTIONAL,
> ./grub-core/loader/i386/bsd.c:    {"serial", 'h',
> GRUB_ARG_OPTION_OPTIONAL,
> ./grub-core/loader/i386/bsd.c:    {"serial", 'h',
> GRUB_ARG_OPTION_OPTIONAL,
>>

Yes, you're right, I missed to make 100% sure that i checked all source
files, mea culpa. That's why i wrote "It seems that there is only one...".

BTW, I spent quite some time to investigate this issue and tried my
best, your reaction is demotivating at least. Just wanna let you know.

Re: [BUG] GRUBs option parsing needs fixing

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 08.03.2012 16:03, Andreas Vogel wrote:
> Am 08.03.2012 15:32, schrieb Vladimir 'φ-coder/phcoder' Serbinenko:
>> On 08.03.2012 15:15, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>>> On 08.03.2012 14:12, Andreas Vogel wrote:
>>>> Hi all,
>>>>
>>>> I start a new thread with this mail in order to have a thread on its
>>>> own
>>>> for this subject.
>>> Please don't CC Colin Watson (or me for that matter) for everything,
>>> it's bad tone.
> I just used Reply-All in my mail program, so please excuse me and I
> really hope that i didn't offend anyone, it was not by purpose.
Don't Reply or Reply-All to start a new thread. It messes up with threading.
>>>> In another thread we've already had some discussion about GRUBs option
>>>> parsing. I wanna summarize and describe here about the issue.
>>>>
>>>> Right now I see 2 problems with GRUBs argument parsing:
>>>>
>>>> 1) GRUBs argum      ent parsing is not POSIX compliant.
>>> We don't follow POSIX.
> But you were telling that you follow GNU, right? And regarding this
> subject GNU follows POSIX, qed.
>
We don't have to recreate whole GNU in GRUB either, we don't write an OS 
but a bootloader. In particular having -xfoo for isn't necessarry and 
moreover it will conflict with
search -su <UUID>
which is already used in the wild.
The case of --long-option optional argument can be changed especially 
taking into account migration from 1.98 but -xfoo is probably out of the 
question.
>


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko

Re: Ideas for the future

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 08.03.2012 16:14, Andreas Vogel wrote:
> Am 08.03.2012 15:11, schrieb Vladimir 'φ-coder/phcoder' Serbinenko:
>> On 05.03.2012 16:43, Andreas Vogel wrote:
>>> Am 05.03.2012 13:54, schrieb Vladimir 'φ-coder/phcoder' Serbinenko:
>>>>> option with an optional argument. By this we would have had what you
>>>>> preference and my way too. Regarding optional arguments the option
>>>>> handling in GRUB is actually broken by design, so this is,
>>>>> unfortunately, not an option.
>>>> When i implemented my patches, i wanted to use both ways: a command
>>>> line
>>>> Again it's unfortunate that noone noticed it when it was committed and
>>>> now we're stuck with it.
>>> You should think about that again. GRUB is broken regarding that and it
>>> should be fixed anyway. Right now it seems that there is only one
>>> command which uses GRUB_ARG_OPTION_OPTIONAL so maybe it's one of the
>>> last chances to have a cheap fix.
>> Learn to use rgrep before making unsupported, easy to check claims:
>> ./grub-core/commands/search_wrap.c:    {"set",        's',
>> GRUB_ARG_OPTION_OPTIONAL,
>> ./grub-core/loader/i386/bsd.c:    {"serial", 'h',
>> GRUB_ARG_OPTION_OPTIONAL,
>> ./grub-core/loader/i386/bsd.c:    {"serial", 'h',
>> GRUB_ARG_OPTION_OPTIONAL,
> Yes, you're right, I missed to make 100% sure that i checked all source
> files, mea culpa. That's why i wrote "It seems that there is only one...".
>
> BTW, I spent quite some time to investigate this issue and tried my
> best, your reaction is demotivating at least. Just wanna let you know.
Sorry about that, I have a lot of things in my head right now (mostly 
not GRUB-related)
>


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko

Re: [BUG] GRUBs option parsing needs fixing

[Lennart Sorensen]

On Thu, Mar 08, 2012 at 02:12:30PM +0100, Andreas Vogel wrote:
> I start a new thread with this mail in order to have a thread on its own
> for this subject.

Actually you did not, you hijacked an existing thread by replying to it
and changing the subject.  Anyone with a threaded mail client now sees
your messages attached to the thread you hijacked.

> In another thread we've already had some discussion about GRUBs option
> parsing. I wanna summarize and describe here about the issue.
> 
> Right now I see 2 problems with GRUBs argument parsing:
> 
> 1) GRUBs argument parsing is not POSIX compliant.
> 
> Problem:
> POSIX (and GNU too) recommends (see
> http://www.gnu.org/software/libc/manual/html_node/Argument-Syntax.html):
> 
> "An option and its argument may or may not appear as separate tokens.
> (In other words, the whitespace separating them is optional.) Thus, ‘-o
> foo’ and ‘-ofoo’ are equivalent."
> 
> This is doesn't hold for GRUB.
> When I try
>     load_env -fenv
> an error message
>     error: unknown argument '-e'.
> is returned.
> 
> Solution:
> The GRUB argument parser needs to be fixed so that short options are
> parsed according to POSIX/GNU standards.
> 
> 2) Optional option argument is not handled correctly (and not according
> to POSIX/GNU standard)
> 
> Problem:
> Right now the GRUB argument parser doesn't handle optional arguments
> properly and it doesn't comply to POSIX/GNU standards.
> 
> For short options parsing fails for the reason described above and
> because the parser allows that the option and its (optional) argument
> might be separated with whitespace.
> 
> For long options parsing fails too because the parser allows that the
> option and its (optional) argument might be separated with whitespace.
> Example:
>     OK: search  --file  --set  --nofloppy  /boot/grub/grub.cfg
>     OK: search  --file  --set  --  /boot/grub/grub.cfg
>     ERROR: search  --file  --set  /boot/grub/grub.cfg
> 
> Solution:
> This solution follows just the POSIX/GNU standards for argument syntax
> as stated in the above mentioned HTML document.
> In order to be able to handle optional arguments for options the GRUB
> argument parser needs to implement parsing according to the following
> syntax:
> 
> a) Short option: e.g. option name 'x' taking an optional argument '<arg>'
>      Possible options: "-x"   or   "-x<arg>"
> 
> b) Long option: e.g. option name 'xlong' taking an optional argument '<arg>'
>      Possible options: "--xlong"   or   "--xlong=<arg>"  or  "--xlong="
>      For the third form the upcoming implementation is somehow free to
> decide how to interpret that option. Regarding to GNUs getopt() man
> page, this form will be interpreted by getopt() as if the option isn't
> specified at all (due to a bug). Because that interpretation is based on
> a bug and because it might make more sense the third form could/should
> be interpreted as if "--xlong" has been specified (meaning: options is
> present but without value).
> 
> So for both, short and long options taking an optional value, no
> whitespace between option and its value (if the value is present) is
> allowed.
> 
> IMHO the option parsing code in GRUB2 should be fixed as soon as
> possible. The later it will be done the more we'll have to fight with
> compatibility issues.
> 
> Any comments?

Well as a user I had never noticed.  I suppose I am used to many programs
requireing spaces around arguments, so I consider those that don't odd,
and those that don't allow spaces to be annoying.

Doesn't mean it wouldn't be nice if grub was consistent with other
GNU things.

-- 
Len Sorensen

Re: [BUG] GRUBs option parsing needs fixing

[Lennart Sorensen]

On Thu, Mar 08, 2012 at 04:03:17PM +0100, Andreas Vogel wrote:
> I just used Reply-All in my mail program, so please excuse me and I
> really hope that i didn't offend anyone, it was not by purpose.

And that is how you hijacked the thread rather than starting a new one.
Subject != thread.

-- 
Len Sorensen

Re: [BUG] GRUBs option parsing needs fixing

[Lennart Sorensen]

On Thu, Mar 08, 2012 at 04:18:05PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> We don't have to recreate whole GNU in GRUB either, we don't write
> an OS but a bootloader. In particular having -xfoo for isn't
> necessarry and moreover it will conflict with
> search -su <UUID>

So a 'short' option that looks like a 'long' option?

Or is that -s and -u together?

Options can get confusing at times?

> which is already used in the wild.
> The case of --long-option optional argument can be changed
> especially taking into account migration from 1.98 but -xfoo is
> probably out of the question.

I don't see how -xfoo where foo is a parameter for -x can work if you
support multiple short options being merged (which seems common in
GNU programs).

-- 
Len Sorensen

Re: [BUG] GRUBs option parsing needs fixing

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 08.03.2012 16:28, Lennart Sorensen wrote:
> On Thu, Mar 08, 2012 at 04:18:05PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>> We don't have to recreate whole GNU in GRUB either, we don't write
>> an OS but a bootloader. In particular having -xfoo for isn't
>> necessarry and moreover it will conflict with
>> search -su<UUID>
> So a 'short' option that looks like a 'long' option?
>
> Or is that -s and -u together?
It's -s and -u together and so -s has no argument. With Andreas 
proposition "u" would be the argument
> Options can get confusing at times?
>
>> which is already used in the wild.
>> The case of --long-option optional argument can be changed
>> especially taking into account migration from 1.98 but -xfoo is
>> probably out of the question.
> I don't see how -xfoo where foo is a parameter for -x can work if you
> support multiple short options being merged (which seems common in
> GNU programs).
You can if when encountering an option needing parameter you parse the 
rest as parameter. But then again optional parameter are tricky.
Behaviour similar to other GNU is important but compatibility with 
previous version of GRUB is more so, especially when it comes to the 
rarely used features like -xfoo.


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko

Re: [BUG] GRUBs option parsing needs fixing

[Andreas Vogel]

Am 08.03.2012 16:18, schrieb Vladimir 'φ-coder/phcoder' Serbinenko:
> On 08.03.2012 16:03, Andreas Vogel wrote:
>> Am 08.03.2012 15:32, schrieb Vladimir 'φ-coder/phcoder' Serbinenko:
>>> On 08.03.2012 15:15, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>>>> On 08.03.2012 14:12, Andreas Vogel wrote:
>>>>> Hi all,
>>>>>
>>>>> I start a new thread with this mail in order to have a thread on its
>>>>> own
>>>>> for this subject.
>>>> Please don't CC Colin Watson (or me for that matter) for everything,
>>>> it's bad tone.
>> I just used Reply-All in my mail program, so please excuse me and I
>> really hope that i didn't offend anyone, it was not by purpose.
> Don't Reply or Reply-All to start a new thread. It messes up with
> threading.

Didn't i write that it was by accident?? What else can i do other than
to beg for pardon?

>>>>> In another thread we've already had some discussion about GRUBs
>>>>> option
>>>>> parsing. I wanna summarize and describe here about the issue.
>>>>>
>>>>> Right now I see 2 problems with GRUBs argument parsing:
>>>>>
>>>>> 1) GRUBs argum      ent parsing is not POSIX compliant.
>>>> We don't follow POSIX.
>> But you were telling that you follow GNU, right? And regarding this
>> subject GNU follows POSIX, qed.
>>
> We don't have to recreate whole GNU in GRUB either, we don't write an
> OS but a bootloader. In particular having -xfoo for isn't necessarry
> and moreover it will conflict with
> search -su <UUID>
> which is already used in the wild.
> The case of --long-option optional argument can be changed especially
> taking into account migration from 1.98 but -xfoo is probably out of
> the question.
>

C'mon, I'm talking about the GNU conventions/recommendations regarding
argument parsing. I'm not talking about the GNU operating system, I
thought I made it clear by even giving the link to that document.

Without being able to parse '-xfoo' you will not be able to handle
optional arguments in a consistent way. Because of this I disagree:
"-xfoo" is necessary.
You are right, "search -su UUID" demonstrates perfectly the weakness of
the actual argument parsing. It's just buggy.
If nothing will be changed for short options, at least you need to
mention in the manual that "search -s -u UUID" is OK but "search -u -s
UUID" is NOT OK.
And you need to mention that "search -su UUID" is OK but "search -us
UUID" is NOT OK.

I'm just mentioning the problems. If you or whoever decide that it's
impossible  to fix this (e.g. because of backward compatibility), that's
another issue. Don't let's mix arguments for how smth should be and what
the consequences will be.

Re: [BUG] GRUBs option parsing needs fixing

[Andreas Vogel]

Am 08.03.2012 16:25, schrieb Lennart Sorensen:
> On Thu, Mar 08, 2012 at 04:03:17PM +0100, Andreas Vogel wrote:
>> I just used Reply-All in my mail program, so please excuse me and I
>> really hope that i didn't offend anyone, it was not by purpose.
> And that is how you hijacked the thread rather than starting a new one.
> Subject != thread.
>

Please... sorry!! What else can i say?

BTW, i even didn't hijack this thread as I'm the starter of it anyway.
Secondly, we already discussed about this issue even in this thread.

Finally, I was writing on my mail until 3 am... and at that time i
wanted it to be just a reply here in this thread. So I saved it. The
next day I decided to start a new thread so that's it will be easier to
find this subject, but I forgot that i used reply previously so when i
finally sent it i noticed then that i did wrong, but it was too late. I
know about the difference between thread and subject - it was just one
(quite unfortunate) mistake.

Re: [BUG] GRUBs option parsing needs fixing

[Andreas Vogel]

Am 08.03.2012 16:37, schrieb Vladimir 'φ-coder/phcoder' Serbinenko:
> On 08.03.2012 16:28, Lennart Sorensen wrote:
>> On Thu, Mar 08, 2012 at 04:18:05PM +0100, Vladimir 'φ-coder/phcoder'
>> Serbinenko wrote:
>>> We don't have to recreate whole GNU in GRUB either, we don't write
>>> an OS but a bootloader. In particular having -xfoo for isn't
>>> necessarry and moreover it will conflict with
>>> search -su<UUID>
>> So a 'short' option that looks like a 'long' option?
>>
>> Or is that -s and -u together?
> It's -s and -u together and so -s has no argument. With Andreas
> proposition "u" would be the argument
Btw, that's the POSIX/GNU proposition. ;)

>> Options can get confusing at times?
>>
>>> which is already used in the wild.
>>> The case of --long-option optional argument can be changed
>>> especially taking into account migration from 1.98 but -xfoo is
>>> probably out of the question.
>> I don't see how -xfoo where foo is a parameter for -x can work if you
>> support multiple short options being merged (which seems common in
>> GNU programs).
> You can if when encountering an option needing parameter you parse the
> rest as parameter. But then again optional parameter are tricky.
> Behaviour similar to other GNU is important but compatibility with
> previous version of GRUB is more so, especially when it comes to the
> rarely used features like -xfoo. 
That's the big misinterpretation done in the past: without being able to
handle "-xfoo" you'll not be able to handle optional arguments in a
proper way. So it's nothing about using a rarely used feature.

The guys writing the POSIX/GNU recommendation did a great job and they
knew exactly what they proposed and for what reasons.

Re: [BUG] GRUBs option parsing needs fixing

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 08.03.2012 16:45, Andreas Vogel wrote:
>> Don't Reply or Reply-All to start a new thread. It messes up with
>> threading.
> Didn't i write that it was by accident??
No you didn't. You explicitly said that you used Reply-All to start a
new thread.
>  What else can i do other than
> to beg for pardon?
If I have something against you, it's your unwillingness to compromise.
With others it's easy to find compromise but with your approach "all or
nothing" it makes the whole thing much more stressful for both of us
without changing the final outcome. That's about basic rules of
communication and cooperation,
> C'mon, I'm talking about the GNU conventions/recommendations regarding
> argument parsing. I'm not talking about the GNU operating system, I
> thought I made it clear by even giving the link to that document.
> Without being able to parse '-xfoo' you will not be able to handle
> optional arguments in a consistent way. Because of this I disagree:
> "-xfoo" is necessary. You are right, "search -su UUID" demonstrates
> perfectly the weakness of the actual argument parsing. It's just buggy.
What is buggy and what isn't depends on what is considered correct. The
syntax "-s root" is widely used and is expected by many people. In fact
many people would consider it a bug if we don'r
> If nothing will be changed for short options, at least you need to
> mention in the manual that "search -s -u UUID" is OK but "search -u -s
> UUID" is NOT OK. And you need to mention that "search -su UUID" is OK
> but "search -us UUID" is NOT OK. I'm just mentioning the problems. If
> you or whoever decide that it's impossible to fix this (e.g. because
> of backward compatibility), that's another issue. Don't let's mix
> arguments for how smth should be and what the consequences will be. 
We're not in Platon's world of ideas. It's irrelevant how it should be.
At the end of the day there are only actions and consequences.

-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko

Re: [BUG] GRUBs option parsing needs fixing

[Andreas Vogel]

Am 10.03.2012 20:50, schrieb Vladimir 'φ-coder/phcoder' Serbinenko:
>>  What else can i do other than
>> to beg for pardon?
> If I have something against you, it's your unwillingness to compromise.
> With others it's easy to find compromise but with your approach "all or
> nothing" it makes the whole thing much more stressful for both of us
> without changing the final outcome. That's about basic rules of
> communication and cooperation,
Sad to hear this, sad that you think about me like this and sad that
you're becoming personal. I just tried to discuss about where I see
problems.
It hurts that you think that I don't follow basic rules of communication
and cooperation.

>> C'mon, I'm talking about the GNU conventions/recommendations regarding
>> argument parsing. I'm not talking about the GNU operating system, I
>> thought I made it clear by even giving the link to that document.
>> Without being able to parse '-xfoo' you will not be able to handle
>> optional arguments in a consistent way. Because of this I disagree:
>> "-xfoo" is necessary. You are right, "search -su UUID" demonstrates
>> perfectly the weakness of the actual argument parsing. It's just buggy.
> What is buggy and what isn't depends on what is considered correct. The
> syntax "-s root" is widely used and is expected by many people. In fact
> many people would consider it a bug if we don'r
Regarding what i read from you until now, you always insisted on being
compatible with GNUs ideas. And you are perfectly right doing so. I
consider GNUs recommendation regarding argument handling to be correct
and very well designed. Imho it would be wise to follow them.
Of course you are right with "-s root", even I was using it that way
until now. The only problem is that the "-s" flag allows the argument to
be optional. Without that we wouldn't have any problem.

>> If nothing will be changed for short options, at least you need to
>> mention in the manual that "search -s -u UUID" is OK but "search -u -s
>> UUID" is NOT OK. And you need to mention that "search -su UUID" is OK
>> but "search -us UUID" is NOT OK. I'm just mentioning the problems. If
>> you or whoever decide that it's impossible to fix this (e.g. because
>> of backward compatibility), that's another issue. Don't let's mix
>> arguments for how smth should be and what the consequences will be. 
> We're not in Platon's world of ideas. It's irrelevant how it should be.
> At the end of the day there are only actions and consequences.
In the text above I'm showing concrete examples why the argument
handling in GRUB is inconsistent and therefore buggy. I cannot remember
that you even confirmed that it's inconsistent.
I wonder why you don't discuss the example I am giving. Am I right with
what i wrote? It's a real question and I hoped that i would get some
constructive feedback.

Maybe we are different in the way we're trying to solve issues: I'm
trying to analyse a problem, see what is wrong and how it should be.
Then I'm thinking about what can be done and what is acceptable and what
are the consequences. Finally it's time for acting. So for me it's
really strange that for you it's irrelevant how it should be.

I just hoped that I could help by identifying and investigating a
problem which I found out when working with GRUB. I wanted to show the
current situation, the problem with it and what would need to be changed
in my opinion. I'm really sorry to be told now that I failed and that my
discussion is not welcomed. This was not my intention and, believe it or
not, I just wanted to help.

Andreas

Re: [BUG] GRUBs option parsing needs fixing

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 5341 bytes --]

On 11.03.2012 01:08, Andreas Vogel wrote:
> Am 10.03.2012 20:50, schrieb Vladimir 'φ-coder/phcoder' Serbinenko:
>>>  What else can i do other than
>>> to beg for pardon?
>> If I have something against you, it's your unwillingness to compromise.
>> With others it's easy to find compromise but with your approach "all or
>> nothing" it makes the whole thing much more stressful for both of us
>> without changing the final outcome. That's about basic rules of
>> communication and cooperation,
> Sad to hear this, sad that you think about me like this and sad that
> you're becoming personal. I just tried to discuss about where I see
> problems.
Yes, I see why you consider the parsing to be a problem.
I believe that we can reach a logical compromise about possible actions.
But we have to both have open mind about the solution.
Actually you remind me of several people including myself, how I was
when I started.
> It hurts that you think that I don't follow basic rules of communication
> and cooperation.
That's the expression I've got. My position shifted somewhat but yours
remains unchanged. You look stubborn from this angle.
>>> C'mon, I'm talking about the GNU conventions/recommendations regarding
>>> argument parsing. I'm not talking about the GNU operating system, I
>>> thought I made it clear by even giving the link to that document.
>>> Without being able to parse '-xfoo' you will not be able to handle
>>> optional arguments in a consistent way. Because of this I disagree:
>>> "-xfoo" is necessary. You are right, "search -su UUID" demonstrates
>>> perfectly the weakness of the actual argument parsing. It's just buggy.
>> What is buggy and what isn't depends on what is considered correct. The
>> syntax "-s root" is widely used and is expected by many people. In fact
>> many people would consider it a bug if we don'r
> Regarding what i read from you until now, you always insisted on being
> compatible with GNUs ideas. And you are perfectly right doing so. I
> consider GNUs recommendation regarding argument handling to be correct
> and very well designed.
But in this case in addition to recommendation there is the reality and
reality of backward compatibility with last several years is important.
>  Imho it would be wise to follow them.
> Of course you are right with "-s root", even I was using it that way
> until now. The only problem is that the "-s" flag allows the argument to
> be optional. Without that we wouldn't have any problem.
Yes. And allowing "-s root" to continue is more important than to allow
-s with no argument.
Actually another possibility is to keep this or this + 2 other
occurencies to this behaviour while making all future uses to the GNU
standards.
We can rename ARG_OPTIONAL to ARG_OLD_OPTIONAL, make ARG_OLD_OPTIONAL to
behave as to ignore X in  --set X as possible argument.
>>> If nothing will be changed for short options, at least you need to
>>> mention in the manual that "search -s -u UUID" is OK but "search -u -s
>>> UUID" is NOT OK. And you need to mention that "search -su UUID" is OK
>>> but "search -us UUID" is NOT OK. I'm just mentioning the problems. If
>>> you or whoever decide that it's impossible to fix this (e.g. because
>>> of backward compatibility), that's another issue. Don't let's mix
>>> arguments for how smth should be and what the consequences will be. 
>> We're not in Platon's world of ideas. It's irrelevant how it should be.
>> At the end of the day there are only actions and consequences.
> In the text above I'm showing concrete examples why the argument
> handling in GRUB is inconsistent and therefore buggy. I cannot remember
> that you even confirmed that it's inconsistent.
> I wonder why you don't discuss the example I am giving. Am I right with
> what i wrote? It's a real question and I hoped that i would get some
> constructive feedback.
I do not see the examples you provided as inconsistent. They might be
unexpected but they are consistent.
> Maybe we are different in the way we're trying to solve issues: I'm
> trying to analyse a problem, see what is wrong and how it should be.
> Then I'm thinking about what can be done and what is acceptable and what
> are the consequences. Finally it's time for acting. So for me it's
> really strange that for you it's irrelevant how it should be.
This is just a way of thinking. The result is action followed by
consequences and this is what counts.
> I just hoped that I could help by identifying and investigating a
> problem which I found out when working with GRUB.
Yes, it is helpful and I'm grateful for it. But there is a limit as to
what can be improved without causing worse nightmare. Old bug is better
than two new ones.
>  I wanted to show the
> current situation, the problem with it and what would need to be changed
> in my opinion. I'm really sorry to be told now that I failed and that my
> discussion is not welcomed.
Discussion is welcomed. Just your messages seem to repeat the same
things over and over and this isn't productive. Be concise and just
write the new elements, not the whole story again every time.
>  This was not my intention and, believe it or
> not, I just wanted to help.
>
> Andreas
>
>


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

Re: [BUG] GRUBs option parsing needs fixing

[Andreas Vogel]

Am 11.03.2012 02:01, schrieb Vladimir 'φ-coder/phcoder' Serbinenko:
>> It hurts that you think that I don't follow basic rules of communication
>> and cooperation.
> That's the expression I've got. My position shifted somewhat but yours
> remains unchanged. You look stubborn from this angle.
Then I'm sorry that I was not able to make it clear what I really
wanted. First of all I wanted to get feedback about my ideas and about
the possibilities for changes.

> Yes. And allowing "-s root" to continue is more important than to allow
> -s with no argument.
Don't get your point here. "-s" with no argument is already allowed.
This is actually causing the "unexpected behavior" I'm talking about.

> Actually another possibility is to keep this or this + 2 other
> occurencies to this behaviour while making all future uses to the GNU
> standards.
I think we are on the same road.

I understand now that it's impossible to change the argument parsing for
existing options taking optional arguments. I was just missing this
clear statement from your side (btw, right now I wonder myself why i
didn't ask you this directly).

I just didn't expect that you would even think about to agree having 3
options to behave the "old" way while allowing a "new" GRUB conformant
way which will be used for new options taking optional arguments.
This is a compromise which I think we really should go for.

> We can rename ARG_OPTIONAL to ARG_OLD_OPTIONAL, make ARG_OLD_OPTIONAL to
> behave as to ignore X in  --set X as possible argument.
I don't understand that.

The "old" behavior, e.g. for "search -s|--set", is that if there is no
argument "-s" or "--set" needs to be followed by another option or by
"--". In other words: any argument which is not an option that follows
-s or --set will be taken as the argument for -s or --set. That's the
current situation.

Re: [BUG] GRUBs option parsing needs fixing

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 1094 bytes --]

On 11.03.2012 02:59, Andreas Vogel wrote:
> Am
>> Yes. And allowing "-s root" to continue is more important than to allow
>> -s with no argument.
> Don't get your point here. "-s" with no argument is already allowed.
> This is actually causing the "unexpected behavior" I'm talking about.
I mean that handling -s root -u UUID is more important than -u -s UUID
since former is widespread in the existing scripts.
>> We can rename ARG_OPTIONAL to ARG_OLD_OPTIONAL, make ARG_OLD_OPTIONAL to
>> behave as to ignore X in  --set X as possible argument.
> I don't understand that.
>
> The "old" behavior, e.g. for "search -s|--set", is that if there is no
> argument "-s" or "--set" needs to be followed by another option or by
> "--". In other words: any argument which is not an option that follows
> -s or --set will be taken as the argument for -s or --set. That's the
> current situation.
I mean changing the behaviour to GNU-like for long but not for short
option. And it actually matches 1.98 behaviour.
>
>
>


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]