status update for grub 2 developments?

status update for grub 2 developments?

[Vesa Jääskeläinen]

Hi all!

I think it would be wise to keep some kind of status updates from time
to time so we can keep track on what people are doing (related to grub
2). If we continue with current situation we are long in 2010's before
we have next release.

I think it would also be important to coordinate more different
activities within grub 2. In example graphical menu has been issue for
several years now :). Therefore I would propose that we would setup a
group of people that would concentrate on specific issues related to
implmentation (like a work group or something). I do not see it as a
requirement that this group of people would implement the feature
(though that would be good), but most importantly to draft out how
features should work. When there is a spec written how feature should
work then it would be much easier to implement that feature and then it
would match ideology of other relevant developers (eg. to get patch
accepted).

I would see that at least following working groups should be formed. Of
course we could tackle design issue at a time and then move to other issues.

- Graphical menu (needs API spec, configuration file specs, guidelines
for implementation, information how to integrate with scripting)

- Network support (needs API spec, driver architecture, protocol stacks,
file system support)

Perhaps some others too... (please add)

Anyway. First of all I would like to hear if you are developing
something above or something else, reply this e-mail and tell us about
it, there is no reason that work should be duplicated. Especially if you
are already developing a feature your words would be good to be heard.
If you are just reporting back list of stuff you are working on, please
keep list as simple and clean as we want only big picture :). You could
also describe how are you progressing with the feature.

Ideas are welcome where to store this information are also welcome :).
We would need to track requirements for features on component level.
More automated the better.

Thanks
Vesa Jääskeläinen

Re: status update for grub 2 developments?

[Robert Millan]

On Sun, Jun 17, 2007 at 03:47:23PM +0300, Vesa Jääskeläinen wrote:
> 
> Anyway. First of all I would like to hear if you are developing
> something above or something else, reply this e-mail and tell us about
> it, there is no reason that work should be duplicated. Especially if you
> are already developing a feature your words would be good to be heard.
> If you are just reporting back list of stuff you are working on, please
> keep list as simple and clean as we want only big picture :). You could
> also describe how are you progressing with the feature.

This site summarises what my GRUB 2 agenda is:

  http://wiki.debian.org/GrubTransition

Things I plan to work on in the near future (days/weeks):

  - Fix OF support (I'm told there was a regression recently).
  - A gettext module (this will wait untill gettext support for util/ is
  implemented, which Jordi Mallach said he would).

Other, more mid-term stuff I might try (weeks/months):

  - Finish EFI grub-install, integration with debian-installer.
  - Commands "splash" and "color".

-- 
Robert Millan

My spam trap is honeypot@aybabtu.com.  Note: this address is only intended
for spam harvesters.  Writing to it will get you added to my black list.

Re: status update for grub 2 developments?

[Ashok kumar]

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

On 6/17/07, Vesa Jääskeläinen <chaac@nic.fi> wrote:
>
> Hi all!
>
> I think it would be wise to keep some kind of status updates from time
> to time so we can keep track on what people are doing (related to grub
> 2). If we continue with current situation we are long in 2010's before
> we have next release.
>
> I think it would also be important to coordinate more different
> activities within grub 2. In example graphical menu has been issue for
> several years now :). Therefore I would propose that we would setup a
> group of people that would concentrate on specific issues related to
> implmentation (like a work group or something). I do not see it as a
> requirement that this group of people would implement the feature
> (though that would be good), but most importantly to draft out how
> features should work. When there is a spec written how feature should
> work then it would be much easier to implement that feature and then it
> would match ideology of other relevant developers (eg. to get patch
> accepted).
>
> I would see that at least following working groups should be formed. Of
> course we could tackle design issue at a time and then move to other
> issues.
>
> - Graphical menu (needs API spec, configuration file specs, guidelines
> for implementation, information how to integrate with scripting)
>
> - Network support (needs API spec, driver architecture, protocol stacks,
> file system support)



I am interested on Network Support.
i am interested on Real tek 8139 driver, which is available in grub legacy
itself.
i am tring to port it for GRUB2.

after completing that, i am interested to invlove on bootp,ifconfig command
development

i am looking for ideas from Network support team members ..


Ashok




Perhaps some others too... (please add)
>
> Anyway. First of all I would like to hear if you are developing
> something above or something else, reply this e-mail and tell us about
> it, there is no reason that work should be duplicated. Especially if you
> are already developing a feature your words would be good to be heard.
> If you are just reporting back list of stuff you are working on, please
> keep list as simple and clean as we want only big picture :). You could
> also describe how are you progressing with the feature.
>
> Ideas are welcome where to store this information are also welcome :).
> We would need to track requirements for features on component level.
> More automated the better.
>
> Thanks
> Vesa Jääskeläinen
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>

[-- Attachment #2: Type: text/html, Size: 3300 bytes --]

Re: status update for grub 2 developments?

[adrian15]

Vesa Jääskeläinen escribió:
> Hi all!
> 
> I think it would be wise to keep some kind of status updates from time
> to time so we can keep track on what people are doing (related to grub
> 2). If we continue with current situation we are long in 2010's before
> we have next release.
You're too optimistic. :) I was thinking about 2015. Anyway,... I will 
work hard this summer in grub2 because it needs it.
> I think it would also be important to coordinate more different
> activities within grub 2.
Ok.
> In example graphical menu has been issue for
> several years now :).
I am sorry not being an expert on this area.
 > Therefore I would propose that we would setup a
> group of people that would concentrate on specific issues related to
> implmentation (like a work group or something).
I also think groups are a good thing.
 > I do not see it as a
> requirement that this group of people would implement the feature
> (though that would be good), but most importantly to draft out how
> features should work. When there is a spec written how feature should
> work then it would be much easier to implement that feature and then it
> would match ideology of other relevant developers (eg. to get patch
> accepted).
I also like the specs idea.
> I would see that at least following working groups should be formed. Of
> course we could tackle design issue at a time and then move to other issues.
> 
> - Graphical menu (needs API spec, configuration file specs, guidelines
> for implementation, information how to integrate with scripting)
I might collaborate on the "how to integrate with scripting" part.
> 
> - Network support (needs API spec, driver architecture, protocol stacks,
> file system support)
No idea about this subject.

> Perhaps some others too... (please add)

I am going to work in grub-disk. A collection of grub2.cfg files or 
maybe more that will define useful collection of command such as Search 
linux kernel, linux initrd and load them. Something similar to Super 
Grub Disk.

> Anyway. First of all I would like to hear if you are developing
> something above or something else, reply this e-mail and tell us about
> it, there is no reason that work should be duplicated.

My current todo:
# Current development
     * pause command
     * map, mapboot and usbshift commands
# Short term development
     * grub-disk scripts
     * grub2 scripts testing
     * grub legacy commands porting
# Long term development
     * install and setup commands for grub2

If you want more details please visit: http://grub.enbug.org/AdrianGibanel

> Ideas are welcome where to store this information are also welcome :).
> We would need to track requirements for features on component level.
> More automated the better.

Can we use the bugs system maybe?
A friend of mine uses trac ( http://trac.edgewall.org/ ) and he likes it 
a lot. I do not know if it fits our needs.

adrian15

Re: status update for grub 2 developments?

[Robert Millan]

On Mon, Jun 18, 2007 at 12:22:47PM +0200, adrian15 wrote:
>     * pause command

How about calling it "read" command, and giving it read-like syntax, to keep
the trend of maintaining some consistency with the GNU cli environment?

> # Short term development
>     * grub-disk scripts

Not sure what you mean with grub-disk scripts.  Do you mean scripts to
generate rescue disks?  If so, then this is already implemented.  Look
at grub-mkrescue in CVS.

(but of course, there's room for improving it)

> >Ideas are welcome where to store this information are also welcome :).
> >We would need to track requirements for features on component level.
> >More automated the better.
> 
> Can we use the bugs system maybe?
> A friend of mine uses trac ( http://trac.edgewall.org/ ) and he likes it 
> a lot. I do not know if it fits our needs.

We have a bug system in Savannah, but it's occupied by GRUB Legacy.  I guess
this is why we're not using it?

Oh btw, are we going to ditch GRUB Legacy anytime soon? :-P

-- 
Robert Millan

My spam trap is honeypot@aybabtu.com.  Note: this address is only intended
for spam harvesters.  Writing to it will get you added to my black list.

Re: status update for grub 2 developments?

[Vesa Jääskeläinen]

Robert Millan wrote:
> On Mon, Jun 18, 2007 at 12:22:47PM +0200, adrian15 wrote:
>>> Ideas are welcome where to store this information are also welcome :).
>>> We would need to track requirements for features on component level.
>>> More automated the better.
>> Can we use the bugs system maybe?
>> A friend of mine uses trac ( http://trac.edgewall.org/ ) and he likes it 
>> a lot. I do not know if it fits our needs.
> 
> We have a bug system in Savannah, but it's occupied by GRUB Legacy.  I guess
> this is why we're not using it?

Bug tracker isn't exactly a tool I was looking for :). With tweaks and
meta bugs some task could be done with it. But I would prefer something
else that savannah's bug tracking facility.

Trac has a bit more features, though I am not familiar enough with it.

Joomla's tracker is a bit more what I was thinking about. It handles
tasks quite nicely. Has task dependency support. It can store files in
tasks so drafts being developed could be stored there. Later specs could
then be stored on Wiki or in doc storage. There is also some reporting
tools... Though they could be a bit better... perhaps anonymous users
just don't see them.

http://joomlacode.org/gf/project/joomla/tracker/

Re: status update for grub 2 developments?

[adrian15]

Robert Millan escribió:
> On Mon, Jun 18, 2007 at 12:22:47PM +0200, adrian15 wrote:
>>     * pause command
> 
> How about calling it "read" command, and giving it read-like syntax, to keep
> the trend of maintaining some consistency with the GNU cli environment?
It's good idea. I also wanted to do something similar to dialog command 
but I am not sure about implementing it or not.
> 
>> # Short term development
>>     * grub-disk scripts
> 
> Not sure what you mean with grub-disk scripts.  Do you mean scripts to
> generate rescue disks?  If so, then this is already implemented.  Look
> at grub-mkrescue in CVS.
Yes and no.
I mean .cfg files.
grub-disk scripts let you build a grub disk.

I want to improve the default grub2 disk that it has some features 
similar to the ones from Super Grub Disk. So that you can find and load 
a linux kernel, find and load a grub2.cfg file, activate partitions, 
browse filesystems and so on.

So I will need to edit grub-mkrescue so that it searches for .cfg in a 
recursive mode on a given folder and generates some new .cfg that link 
to the other ones as if there was jerarquical menu.

adrian15

Re: status update for grub 2 developments?

[adrian15]

Vesa Jääskeläinen escribió:
> Joomla's tracker is a bit more what I was thinking about. It handles
> tasks quite nicely. Has task dependency support.

	I think that gforge has also tasks. I just do not find right now any 
gforge site with a task site.

adrian15

Re: status update for grub 2 developments?

[Vesa Jääskeläinen]

adrian15 wrote:
> Vesa Jääskeläinen escribió:
>> Joomla's tracker is a bit more what I was thinking about. It handles
>> tasks quite nicely. Has task dependency support.
> 
>     I think that gforge has also tasks. I just do not find right now any
> gforge site with a task site.

Joomla's tracker is based on GForge ;)

Re: status update for grub 2 developments?

[Marco Gerards]

Vesa Jääskeläinen <chaac@nic.fi> writes:

Hi Vesa,

> I think it would be wise to keep some kind of status updates from time
> to time so we can keep track on what people are doing (related to grub
> 2). If we continue with current situation we are long in 2010's before
> we have next release.

Agreed, we should head to he next release now.

> I think it would also be important to coordinate more different
> activities within grub 2. In example graphical menu has been issue for
> several years now :). Therefore I would propose that we would setup a
> group of people that would concentrate on specific issues related to
> implmentation (like a work group or something). I do not see it as a
> requirement that this group of people would implement the feature
> (though that would be good), but most importantly to draft out how
> features should work. When there is a spec written how feature should
> work then it would be much easier to implement that feature and then it
> would match ideology of other relevant developers (eg. to get patch
> accepted).

Right, it's a big problem that people send in patches that do not
match what we had in mind.  Writing down things can prevent such
problems.  We can use the wiki for that.  But in the longer term we
need something with more structure.

> I would see that at least following working groups should be formed. Of
> course we could tackle design issue at a time and then move to other issues.
>
> - Graphical menu (needs API spec, configuration file specs, guidelines
> for implementation, information how to integrate with scripting)
>
> - Network support (needs API spec, driver architecture, protocol stacks,
> file system support)

Actually, I thought a lot about networking.  I even have some code.

As you know I will be working on ffmpeg during the summer.  I will try
to free some evenings and weekends for GRUB 2 work.  In that time I
will try to finish scripting support and networking.

> Perhaps some others too... (please add)

People worked on all kinds of ports.  Some patches have not been
committed and suffer from bit rot.  The main problems were that the
maintainers didn't have much time lately and the patches were big huge
chunks of code.

Something I think is important for GRUB 2 is regression testing.  So
we can make sure things like scripting works, filesystems work
correctly, etc.

Another thing is the PPC port.  We need a macos loader.  It is high
priority if we want to replace yaboot.

> Anyway. First of all I would like to hear if you are developing
> something above or something else, reply this e-mail and tell us about
> it, there is no reason that work should be duplicated. Especially if you
> are already developing a feature your words would be good to be heard.
> If you are just reporting back list of stuff you are working on, please
> keep list as simple and clean as we want only big picture :). You could
> also describe how are you progressing with the feature.

Well, if people want to work on scripting or networking they should
talk to me.  I have lots of code on my hd that is incomplete or just
not cleaned up.  It would be a waste of time if it were rewritten.
And please poke me a lot to get me to work... ;)

> Ideas are welcome where to store this information are also welcome :).
> We would need to track requirements for features on component level.
> More automated the better.

Something like savannah.  Okuji doesn't like savannah that much,
IIRC.  And I don't either.  But I agree that too much goes wrong to
keep on working this way.

--
Marco

Re: status update for grub 2 developments?

[Bean]

On Sat, Jun 23, 2007 at 02:57:30PM +0200, Marco Gerards wrote:
> Something I think is important for GRUB 2 is regression testing.  So
> we can make sure things like scripting works, filesystems work
> correctly, etc.

I can't agree more. I think major bug should be fixed as soon as possible,
otherwise grub2 wouldn't be that useful.

> Well, if people want to work on scripting or networking they should
> talk to me.  I have lots of code on my hd that is incomplete or just
> not cleaned up.  It would be a waste of time if it were rewritten.
> And please poke me a lot to get me to work... ;)

I'm interested in scripting. What could I do to help you ?

-- 
Bean <bean123@126.com>

Re: status update for grub 2 developments?

[Marco Gerards]

Bean <bean123@126.com> writes:

> On Sat, Jun 23, 2007 at 02:57:30PM +0200, Marco Gerards wrote:
>> Something I think is important for GRUB 2 is regression testing.  So
>> we can make sure things like scripting works, filesystems work
>> correctly, etc.
>
> I can't agree more. I think major bug should be fixed as soon as possible,
> otherwise grub2 wouldn't be that useful.
>
>> Well, if people want to work on scripting or networking they should
>> talk to me.  I have lots of code on my hd that is incomplete or just
>> not cleaned up.  It would be a waste of time if it were rewritten.
>> And please poke me a lot to get me to work... ;)
>
> I'm interested in scripting. What could I do to help you ?

For example, you could implement the expr command.  For that you
need to write a simple expression parser.  It should just be like you
use on the console (see "man expr").  You could even use bison, or
write a recursive descent parser.

Another thing you can do is going over my code.  Check if it is sane,
makes sense, etc.  I am the first person to admit that I am no parser
expert.  There was just no one else doing this the way I wanted, so I
just picked up this task.

So you could figure out how things work, figure out if things can be
improved or cleaned up (especially the memory handling and lexer).
This is a hard task because you have to understand the code.  But it
leaves you in a position to fix bugs and improve the design and even
extend it!

Feel free to ask lots of questions.  I rather tell you on beforehand
how things should be done, instead of telling your patches are wrong.
IRC can, for example, be a good way to discuss some things like these.

--
Marco

Re: status update for grub 2 developments?

[Marco Gerards]

Bean <bean123@126.com> writes:

> On Sat, Jun 23, 2007 at 02:57:30PM +0200, Marco Gerards wrote:
>> Something I think is important for GRUB 2 is regression testing.  So
>> we can make sure things like scripting works, filesystems work
>> correctly, etc.
>
> I can't agree more. I think major bug should be fixed as soon as possible,
> otherwise grub2 wouldn't be that useful.

BTW, did you notice any major bugs?  Please document them on the
wiki.  It's not ideal for this, but it is at least something.

--
Marco

Re: status update for grub 2 developments?

[Bean]

On Sat, Jun 23, 2007 at 04:52:34PM +0200, Marco Gerards wrote:
> Bean <bean123@126.com> writes:
> 
> > On Sat, Jun 23, 2007 at 02:57:30PM +0200, Marco Gerards wrote:
> >> Something I think is important for GRUB 2 is regression testing.  So
> >> we can make sure things like scripting works, filesystems work
> >> correctly, etc.
> >
> > I can't agree more. I think major bug should be fixed as soon as possible,
> > otherwise grub2 wouldn't be that useful.
> 
> BTW, did you notice any major bugs?  Please document them on the
> wiki.  It's not ideal for this, but it is at least something.

I didn't find any major bug, just a few minor ones. For example, the
blocklist command seems to generate messy result when compared to GRUB
Legacy.

btw, I think the wiki is not very convenient, something like a forum would
be much better.

-- 
Bean <bean123@126.com>

Re: status update for grub 2 developments?

[Marco Gerards]

Bean <bean123@126.com> writes:

> On Sat, Jun 23, 2007 at 04:52:34PM +0200, Marco Gerards wrote:
>> Bean <bean123@126.com> writes:
>> 
>> > On Sat, Jun 23, 2007 at 02:57:30PM +0200, Marco Gerards wrote:
>> >> Something I think is important for GRUB 2 is regression testing.  So
>> >> we can make sure things like scripting works, filesystems work
>> >> correctly, etc.
>> >
>> > I can't agree more. I think major bug should be fixed as soon as possible,
>> > otherwise grub2 wouldn't be that useful.
>> 
>> BTW, did you notice any major bugs?  Please document them on the
>> wiki.  It's not ideal for this, but it is at least something.
>
> I didn't find any major bug, just a few minor ones. For example, the
> blocklist command seems to generate messy result when compared to GRUB
> Legacy.
>
> btw, I think the wiki is not very convenient, something like a forum would
> be much better.

Well, that's what a mailinglist is for.

The best thing, according to most people working on GRUB (from what I
can tell) is a bug tracking system combined with something that tracks
tasks, what people are interested on, descriptions of how tasks should
be performed, etc.  That is something I like as well.

--
Marco

Re: status update for grub 2 developments?

[Bean]

On Sat, Jun 23, 2007 at 06:10:10PM +0200, Marco Gerards wrote:
> The best thing, according to most people working on GRUB (from what I
> can tell) is a bug tracking system combined with something that tracks
> tasks, what people are interested on, descriptions of how tasks should
> be performed, etc.  That is something I like as well.

I notice that savannah has a bug tracking system, but it's filled with
stuff from GRUB Legacy, maybe grub2 should have a tracking system of its
own.

-- 
Bean <bean123@126.com>

Re: status update for grub 2 developments?

[Marco Gerards]

Bean <bean123@126.com> writes:

> On Sat, Jun 23, 2007 at 06:10:10PM +0200, Marco Gerards wrote:
>> The best thing, according to most people working on GRUB (from what I
>> can tell) is a bug tracking system combined with something that tracks
>> tasks, what people are interested on, descriptions of how tasks should
>> be performed, etc.  That is something I like as well.
>
> I notice that savannah has a bug tracking system, but it's filled with
> stuff from GRUB Legacy, maybe grub2 should have a tracking system of its
> own.

Yes.  The question is what it will be.

--
Marco

Re: status update for grub 2 developments?

[Yoshinori K. Okuji]

On Saturday 23 June 2007 18:38, Marco Gerards wrote:
> Bean <bean123@126.com> writes:
> > On Sat, Jun 23, 2007 at 06:10:10PM +0200, Marco Gerards wrote:
> >> The best thing, according to most people working on GRUB (from what I
> >> can tell) is a bug tracking system combined with something that tracks
> >> tasks, what people are interested on, descriptions of how tasks should
> >> be performed, etc.  That is something I like as well.
> >
> > I notice that savannah has a bug tracking system, but it's filled with
> > stuff from GRUB Legacy, maybe grub2 should have a tracking system of its
> > own.
>
> Yes.  The question is what it will be.

No. I never recommend using external resources. Even though the bug tracker on 
Savannah sucks, it is more or less usable. You can add a new field with which 
you can indicate whether your version is legacy or 2.

People often tend to think about software quality, but the really important 
thing in services is the maintenance. It is surely easy to set up a server, 
but it is very tough to maintain such a server for years (especially without 
being paid), dealing with hardware and software failures, answering silly 
questions, taking care of vulnerabilities, and so on.

gnu.org is maintained. It is financially supported. Even if the software is 
far from the best, you should use it. If you are not satisfied, improve 
savane rather than going away.

You might want to think of another web site. But is there any good alternative 
to savannah, from the viewpoint of functions as well as software freedom? And 
is there any good reason that we, a part of the GNU project, would like to 
abandone savannah and move away to anything else?

Please consider my words carefully, before proposing not using savannah.

(The wiki is exceptional, but as you might know, I was working on implementing 
wiki support in savane some years ago, but I could not finish it due to lack 
of time. If anybody can finish it, I would be happy to throw away our own 
wiki site, and move to savannah.)

Okuji

Re: status update for grub 2 developments?

[Bean]

Some bugs I found on scripting.

1. token parser

echo aa"bb"
aabb
(correct)

echo aa"bb"cc
aabb
(cc is lost)

echo aa$prefix
aa (hd0,1)/boot/grub
(should be one token)

echo $prefix/grub.cfg
(hd0,1)/boot/grub /grub.cfg
(should be one token)

The problem here is that when a variable is mixed with text, the token breaks.
I think this is also the reason why set doesn't work with variable.

set AA=1
set BB=$AA

will expand to

set AA=1
set BB= 1

Thereforce the value of BB is empty instead of 1.

2. function

There are a lot of problem with function.

I put this in grub.cfg:

function aa {
  set AA=gfxterm
  insmod $AA
}

And grub goes into an infinite loop:
syntax error
Incorrect command
syntax error
Incorrect command
...

But if I rewrite the function as
function aa {
  set AA=gfxterm
  insmod ${AA}
}

It display the menu properly.

Howerver, when I go to the grub console, and enter aa, it says:

error: unknown command `aa'

and lsmod shows no gfxterm module.

If I use aa before the first menuentry, the menu is not even displayed !

I put anothe function in grub.cfg:
function bb {
  ls (hd0,1)/
}

enter console mode, enter bb:
error: unknown command `ls'

After this, ls command will fail.

Howerver, if I use ls before bb, it says:
error: unknow device

Later use of the ls command works.

Note: ls is not bundled in core.img.

Another function:
function cc {
  set AA=1
  echo ${AA}
}

This is similar to the bb example. If I use echo before cc, it says:
1
error: unknown command `cc'

If I use cc directly, it says:
error: unknow command `echo'

And later use of echo will fail.

-- 
Bean <bean123@126.com>

Re: status update for grub 2 developments?

[Bean]

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

On Sun, Jun 24, 2007 at 12:22:18PM +0800, Bean wrote:
> Some bugs I found on scripting.
> 
> 1. token parser
> 
> echo aa"bb"
> aabb
> (correct)
> 
> echo aa"bb"cc
> aabb
> (cc is lost)
> 
> echo aa$prefix
> aa (hd0,1)/boot/grub
> (should be one token)
> 
> echo $prefix/grub.cfg
> (hd0,1)/boot/grub /grub.cfg
> (should be one token)
> 
> The problem here is that when a variable is mixed with text, the token breaks.
> I think this is also the reason why set doesn't work with variable.
> 
> set AA=1
> set BB=$AA
> 
> will expand to
> 
> set AA=1
> set BB= 1
> 
> Thereforce the value of BB is empty instead of 1.
> 

I fix the token parser problem, changes include:

1. Inside grub_script_yylex2, mixed text is detected, and transformed into
arg structure instead of text.

2. Fix a small bug that cause trash output when an undefine variable is
referenced.

3. Close varible definition when / is encountered.

With this patch, the following command works properly:

echo aa"BB"cc
aaBBcc

set AA=1
set BB=$AA
echo $BB
1

echo $prefix/grub.cfg
(hd0,1)/boot/grub/grub.cfg

echo ${prefix}/grub.cfg
(hd0,1)/boot/grub/grub.cfg

set AA=1
echo aa"$AA"bb
aa1bb

echo aa${?}bb
aa0bb

-- 
Bean <bean123@126.com>

[-- Attachment #2: grub2-parser.diff --]
[-- Type: text/plain, Size: 13781 bytes --]

2007-06-24  Bean  <bean123@126.com>

	* kern/parser.c (state_transitions): Add new case.

	* normal/execute.c (grub_script_argument_to_string):
	Output empty string when variable does not exist.

	* normal/lexer.c (grub_script_yylex2): Handle mixed text
	properly.

	* normal/parser.y : token GRUB_PARSER_TOKEN_VAR returns arg
	instead of text.


Index: kern/parser.c
===================================================================
RCS file: /sources/grub/grub2/kern/parser.c,v
retrieving revision 1.2
diff -u -r1.2 parser.c
--- kern/parser.c	23 Nov 2005 03:36:24 -0000	1.2
+++ kern/parser.c	24 Jun 2007 11:23:48 -0000
@@ -44,6 +44,7 @@
   { GRUB_PARSER_STATE_VAR, GRUB_PARSER_STATE_VARNAME2, '{', 0},
   { GRUB_PARSER_STATE_VAR, GRUB_PARSER_STATE_VARNAME, 0, 1},
   { GRUB_PARSER_STATE_VARNAME, GRUB_PARSER_STATE_TEXT, ' ', 1},
+  { GRUB_PARSER_STATE_VARNAME, GRUB_PARSER_STATE_TEXT, '/', 1},
   { GRUB_PARSER_STATE_VARNAME2, GRUB_PARSER_STATE_TEXT, '}', 0},
 
   { GRUB_PARSER_STATE_QVAR, GRUB_PARSER_STATE_QVARNAME2, '{', 0},
Index: normal/execute.c
===================================================================
RCS file: /sources/grub/grub2/normal/execute.c,v
retrieving revision 1.4
diff -u -r1.4 execute.c
--- normal/execute.c	28 May 2006 21:58:34 -0000	1.4
+++ normal/execute.c	24 Jun 2007 11:23:48 -0000
@@ -50,7 +50,8 @@
       if (argi->type == 1)
 	{
 	  val = grub_env_get (argi->str);
-	  size += grub_strlen (val);
+	  if (val)
+	    size += grub_strlen (val);
 	}
       else
 	size += grub_strlen (argi->str);
@@ -68,7 +69,8 @@
       if (argi->type == 1)
 	{
 	  val = grub_env_get (argi->str);
-	  grub_strcat (chararg, val);
+	  if (val)
+	    grub_strcat (chararg, val);
 	}
       else
 	grub_strcat (chararg, argi->str);
Index: normal/lexer.c
===================================================================
RCS file: /sources/grub/grub2/normal/lexer.c,v
retrieving revision 1.6
diff -u -r1.6 lexer.c
--- normal/lexer.c	4 Jun 2006 15:56:55 -0000	1.6
+++ normal/lexer.c	24 Jun 2007 11:23:48 -0000
@@ -50,7 +50,7 @@
   struct grub_lexer_param *param;
 
   param = grub_malloc (sizeof (*param));
-  if (! param)
+  if (!param)
     return 0;
 
   param->state = GRUB_PARSER_STATE_TEXT;
@@ -100,7 +100,7 @@
       if (state->recording[--state->recordpos] != '}')
 	{
 	  grub_printf ("Internal error while parsing menu entry");
-	  for (;;); /* XXX */
+	  for (;;);		/* XXX */
 	}
       state->recording[state->recordpos] = '\0';
     }
@@ -118,7 +118,7 @@
       char *old = state->recording;
       state->recordlen += 100;
       state->recording = grub_realloc (state->recording, state->recordlen);
-      if (! state->recording)
+      if (!state->recording)
 	{
 	  grub_free (old);
 	  state->record = 0;
@@ -137,10 +137,10 @@
 }
 
 int
-grub_script_yylex2 (YYSTYPE *yylval, struct grub_parser_param *parsestate);
+grub_script_yylex2 (YYSTYPE * yylval, struct grub_parser_param *parsestate);
 
 int
-grub_script_yylex (YYSTYPE *yylval, struct grub_parser_param *parsestate)
+grub_script_yylex (YYSTYPE * yylval, struct grub_parser_param *parsestate)
 {
   int r = -1;
 
@@ -154,31 +154,32 @@
 }
 
 int
-grub_script_yylex2 (YYSTYPE *yylval, struct grub_parser_param *parsestate)
+grub_script_yylex2 (YYSTYPE * yylval, struct grub_parser_param *parsestate)
 {
   grub_parser_state_t newstate;
   char use;
   char *buffer;
   char *bp;
   struct grub_lexer_param *state = parsestate->lexerstate;
+  struct grub_script_arg *arg = 0;
+  int done = 0;
 
   if (state->done)
     return 0;
 
-  if (! *state->script)
+  if (!*state->script)
     {
       /* Check if more tokens are requested by the parser.  */
       if ((state->refs
-	   || state->state == GRUB_PARSER_STATE_ESC)
-	  && state->getline)
+	   || state->state == GRUB_PARSER_STATE_ESC) && state->getline)
 	{
-	  while (!state->script || ! grub_strlen (state->script))
+	  while (!state->script || !grub_strlen (state->script))
 	    {
 	      grub_free (state->newscript);
 	      state->newscript = 0;
 	      state->getline (&state->newscript);
 	      state->script = state->newscript;
-	      if (! state->script)
+	      if (!state->script)
 		return 0;
 	    }
 	  grub_dprintf ("scripting", "token=`\\n'\n");
@@ -196,163 +197,192 @@
 	}
     }
 
-  newstate = grub_parser_cmdline_state (state->state, *state->script, &use);
-
-  /* Check if it is a text.  */
-  if (check_textstate (newstate))
+  while (1)
     {
-      /* In case the string is not quoted, this can be a one char
-	 length symbol.  */
-      if (newstate == GRUB_PARSER_STATE_TEXT)
+      newstate =
+	grub_parser_cmdline_state (state->state, *state->script, &use);
+
+      /* Check if it is a text.  */
+      if (check_textstate (newstate))
 	{
-	  switch (*state->script)
+	  /* In case the string is not quoted, this can be a one char
+	     length symbol.  */
+	  if (newstate == GRUB_PARSER_STATE_TEXT)
 	    {
-	    case ' ':
-	      while (*state->script)
+	      switch (*state->script)
 		{
-		  newstate = grub_parser_cmdline_state (state->state,
-							*state->script, &use);
-		  if (! (state->state == GRUB_PARSER_STATE_TEXT
-			 && *state->script == ' '))
+		case ' ':
+		  while (*state->script)
 		    {
-		      grub_dprintf ("scripting", "token=` '\n");
-		      return ' ';
+		      newstate = grub_parser_cmdline_state (state->state,
+							    *state->script,
+							    &use);
+		      if (!
+			  (state->state == GRUB_PARSER_STATE_TEXT
+			   && *state->script == ' '))
+			{
+			  grub_dprintf ("scripting", "token=` '\n");
+			  return ' ';
+			}
+		      state->state = newstate;
+		      nextchar (state);
 		    }
-		  state->state = newstate;
-		  nextchar (state);
+		  grub_dprintf ("scripting", "token=` '\n");
+		  return ' ';
+		case '{':
+		case '}':
+		case ';':
+		case '\n':
+		  {
+		    char c;
+		    grub_dprintf ("scripting", "token=`%c'\n",
+				  *state->script);
+		    c = *state->script;;
+		    nextchar (state);
+		    return c;
+		  }
 		}
-	      grub_dprintf ("scripting", "token=` '\n");
-	      return ' ';
-	    case '{':
-	    case '}':
-	    case ';':
-	    case '\n':
-	      {
-		char c;
-		grub_dprintf ("scripting", "token=`%c'\n", *state->script);
-		c = *state->script;;
-		nextchar (state);
-		return c;
-	      }
 	    }
-	}
-
-      /* XXX: Use a better size.  */
-      buffer = grub_script_malloc (parsestate, 2048);
-      if (! buffer)
-	return 0;
 
-      bp = buffer;
+	  /* XXX: Use a better size.  */
+	  buffer = grub_script_malloc (parsestate, 2048);
+	  if (!buffer)
+	    return 0;
 
-      /* Read one token, possible quoted.  */
-      while (*state->script)
-	{
-	  newstate = grub_parser_cmdline_state (state->state,
-						*state->script, &use);
+	  bp = buffer;
 
-	  /* Check if a variable name starts.  */
-	  if (check_varstate (newstate))
-	    break;
-
-	  /* If the string is not quoted or escaped, stop processing
-	     when a special token was found.  It will be recognised
-	     next time when this function is called.  */
-	  if (newstate == GRUB_PARSER_STATE_TEXT
-	      && state->state != GRUB_PARSER_STATE_ESC)
+	  /* Read one token, possible quoted.  */
+	  while (*state->script)
 	    {
-	      int breakout = 0;
+	      newstate = grub_parser_cmdline_state (state->state,
+						    *state->script, &use);
+
+	      /* Check if a variable name starts.  */
+	      if (check_varstate (newstate))
+		break;
 
-	      switch (use)
+	      /* If the string is not quoted or escaped, stop processing
+	         when a special token was found.  It will be recognised
+	         next time when this function is called.  */
+	      if (newstate == GRUB_PARSER_STATE_TEXT
+		  && state->state != GRUB_PARSER_STATE_ESC)
 		{
-		case ' ':
-		case '{':
-		case '}':
-		case ';':
-		case '\n':
-		  breakout = 1;
+		  switch (use)
+		    {
+		    case ' ':
+		    case '{':
+		    case '}':
+		    case ';':
+		    case '\n':
+		      done = 1;
+		    }
+		  if (done)
+		    break;
 		}
-	      if (breakout)
-		break;
-	      *(bp++) = use;
+
+	      if (use)
+		*(bp++) = use;
+
+	      state->state = newstate;
+	      nextchar (state);
 	    }
-	  else if (use)
-	    *(bp++) = use;
 
-	  state->state = newstate;
-	  nextchar (state);
-	}
+	  /* A string of text was read in.  */
+	  *bp = '\0';
+	  grub_dprintf ("scripting", "token=`%s'\n", buffer);
 
-      /* A string of text was read in.  */
-      *bp = '\0';
-      grub_dprintf ("scripting", "token=`%s'\n", buffer);
-      yylval->string = buffer;
-
-      /* Detect some special tokens.  */
-      if (! grub_strcmp (buffer, "while"))
-	return GRUB_PARSER_TOKEN_WHILE;
-      else if (! grub_strcmp (buffer, "if"))
-	return GRUB_PARSER_TOKEN_IF;
-      else if (! grub_strcmp (buffer, "function"))
-	return GRUB_PARSER_TOKEN_FUNCTION;
-      else if (! grub_strcmp (buffer, "menuentry"))
-	return GRUB_PARSER_TOKEN_MENUENTRY;
-      else if (! grub_strcmp (buffer, "@"))
-	return GRUB_PARSER_TOKEN_MENUENTRY;
-      else if (! grub_strcmp (buffer, "else"))
-	return GRUB_PARSER_TOKEN_ELSE;
-      else if (! grub_strcmp (buffer, "then"))
-	return GRUB_PARSER_TOKEN_THEN;
-      else if (! grub_strcmp (buffer, "fi"))
-	return GRUB_PARSER_TOKEN_FI;
-      else
-	return GRUB_PARSER_TOKEN_NAME;
-    }
-  else if (newstate == GRUB_PARSER_STATE_VAR
-	   || newstate == GRUB_PARSER_STATE_QVAR)
-    {
-      /* XXX: Use a better size.  */
-      buffer = grub_script_malloc (parsestate, 2096);
-      if (! buffer)
-	return 0;
+	  if (!*state->script)
+	    done = 1;
 
-      bp = buffer;
+	  if ((done) && (!arg))
+	    {
+	      yylval->string = buffer;
+
+	      /* Detect some special tokens.  */
+	      if (!grub_strcmp (buffer, "while"))
+		return GRUB_PARSER_TOKEN_WHILE;
+	      else if (!grub_strcmp (buffer, "if"))
+		return GRUB_PARSER_TOKEN_IF;
+	      else if (!grub_strcmp (buffer, "function"))
+		return GRUB_PARSER_TOKEN_FUNCTION;
+	      else if (!grub_strcmp (buffer, "menuentry"))
+		return GRUB_PARSER_TOKEN_MENUENTRY;
+	      else if (!grub_strcmp (buffer, "@"))
+		return GRUB_PARSER_TOKEN_MENUENTRY;
+	      else if (!grub_strcmp (buffer, "else"))
+		return GRUB_PARSER_TOKEN_ELSE;
+	      else if (!grub_strcmp (buffer, "then"))
+		return GRUB_PARSER_TOKEN_THEN;
+	      else if (!grub_strcmp (buffer, "fi"))
+		return GRUB_PARSER_TOKEN_FI;
+	      else
+		return GRUB_PARSER_TOKEN_NAME;
+	    }
 
-      /* This is a variable, read the variable name.  */
-      while (*state->script)
+	  if (bp != buffer)
+	    arg =
+	      grub_script_arg_add (parsestate, arg, GRUB_SCRIPT_ARG_TYPE_STR,
+				   buffer);
+	}
+      else if (newstate == GRUB_PARSER_STATE_VAR
+	       || newstate == GRUB_PARSER_STATE_QVAR)
 	{
-	  newstate = grub_parser_cmdline_state (state->state,
-						*state->script, &use);
+	  /* XXX: Use a better size.  */
+	  buffer = grub_script_malloc (parsestate, 2096);
+	  if (!buffer)
+	    return 0;
+
+	  bp = buffer;
 
-	  /* Check if this character is not part of the variable name
-	     anymore.  */
-	  if (! (check_varstate (newstate)))
+	  /* This is a variable, read the variable name.  */
+	  while (*state->script)
 	    {
-	      if (state->state == GRUB_PARSER_STATE_VARNAME2
-		  || state->state == GRUB_PARSER_STATE_QVARNAME2)
-		nextchar (state);
+	      newstate = grub_parser_cmdline_state (state->state,
+						    *state->script, &use);
+
+	      /* Check if this character is not part of the variable name
+	         anymore.  */
+	      if (!(check_varstate (newstate)))
+		{
+		  if (state->state == GRUB_PARSER_STATE_VARNAME2
+		      || state->state == GRUB_PARSER_STATE_QVARNAME2)
+		    nextchar (state);
+		  state->state = newstate;
+		  break;
+		}
+
+	      if (use)
+		*(bp++) = use;
+	      nextchar (state);
 	      state->state = newstate;
-	      break;
 	    }
 
-	  if (use)
-	    *(bp++) = use;
-	  nextchar (state);
+	  *bp = '\0';
 	  state->state = newstate;
-	}
 
-      *bp = '\0';
-      state->state = newstate;
-      yylval->string = buffer;
-      grub_dprintf ("scripting", "vartoken=`%s'\n", buffer);
+	  if (bp != buffer)
+	    arg =
+	      grub_script_arg_add (parsestate, arg, GRUB_SCRIPT_ARG_TYPE_VAR,
+				   buffer);
+	}
+      else
+	{
+	  /* There is either text or a variable name.  In the case you
+	     arrive here there is a serious problem with the lexer.  */
+	  grub_error (GRUB_ERR_BAD_ARGUMENT, "Internal error\n");
+	  return 0;
+	}
 
-      return GRUB_PARSER_TOKEN_VAR;
-    }
-  else
-    {
-      /* There is either text or a variable name.  In the case you
-	 arrive here there is a serious problem with the lexer.  */
-      grub_error (GRUB_ERR_BAD_ARGUMENT, "Internal error\n");
-      return 0;
+      if ((done) || (!*state->script))
+	{
+	  if (arg)
+	    {
+	      yylval->arg = arg;
+	      return GRUB_PARSER_TOKEN_VAR;
+	    }
+	  else
+	    return ' ';
+	}
     }
 }
 
Index: normal/parser.y
===================================================================
RCS file: /sources/grub/grub2/normal/parser.y,v
retrieving revision 1.6
diff -u -r1.6 parser.y
--- normal/parser.y	4 Jun 2006 15:56:55 -0000	1.6
+++ normal/parser.y	24 Jun 2007 11:23:48 -0000
@@ -46,9 +46,9 @@
 %token GRUB_PARSER_TOKEN_VAR
 %type <cmd> script grubcmd command commands commandblock menuentry if
 %type <arglist> arguments;
-%type <arg> argument;
+%type <arg> argument GRUB_PARSER_TOKEN_VAR;
 %type <string> "if" "while" "function" "else" "then" "fi"
-%type <string> text GRUB_PARSER_TOKEN_NAME GRUB_PARSER_TOKEN_VAR
+%type <string> text GRUB_PARSER_TOKEN_NAME
 
 %pure-parser
 %lex-param { struct grub_parser_param *state };
@@ -86,7 +86,7 @@
    for example: `foo${bar}baz'.  */
 argument:	GRUB_PARSER_TOKEN_VAR
 		  {
-		    $$ = grub_script_arg_add (state, 0, GRUB_SCRIPT_ARG_TYPE_VAR, $1);
+		    $$ = $1;
 		  }
 		| text
 		  {

Re: status update for grub 2 developments?

[Bean]

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

On Sun, Jul 01, 2007 at 07:49:20PM +0200, adrian15 wrote:
> Bean escribió:
> >>Well, if people want to work on scripting or networking they should
> >>talk to me.  I have lots of code on my hd that is incomplete or just
> >>not cleaned up.  It would be a waste of time if it were rewritten.
> >>And please poke me a lot to get me to work... ;)
> >
> >I'm interested in scripting. What could I do to help you ?
> 
> 	As long as you may re-read Marco_g source code you can try to fix a 
> 	bug
> that I have found I suppose in the parser.
> 
> 	If you type any command with a \ character not being inside " "
> characters it gives an grub internal error.
> 
> 	echo "\n"		--> OK
> 	echo \n fff 		--> GRUB INTERNAL ERROR

It's fixed, please test.

echo "\n"
\n

echo \n fff
n fff

Note: you need to apply the patch grub2-parser-u2.diff first.

-- 
Bean

[-- Attachment #2: grub2-parser-u2-1.diff --]
[-- Type: text/plain, Size: 604 bytes --]

	* normal/lexer.c (check_textstate): Add GRUB_PARSER_STATE_ESC.


Index: normal/lexer.c
===================================================================
RCS file: /sources/grub/grub2/normal/lexer.c,v
retrieving revision 1.6
diff -u -r1.6 lexer.c
--- normal/lexer.c	4 Jun 2006 15:56:55 -0000	1.6
+++ normal/lexer.c	25 Jun 2007 18:27:59 -0000
@@ -41,7 +41,8 @@
 {
   return (state == GRUB_PARSER_STATE_TEXT
 	  || state == GRUB_PARSER_STATE_QUOTE
-	  || state == GRUB_PARSER_STATE_DQUOTE);
+	  || state == GRUB_PARSER_STATE_DQUOTE
+	  || state == GRUB_PARSER_STATE_ESC);
 }
 
 struct grub_lexer_param *

Re: status update for grub 2 developments?

[Ashok kumar]

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

On 6/23/07, Marco Gerards <mgerards@xs4all.nl> wrote:
>
> Vesa Jääskeläinen <chaac@nic.fi> writes:
>
> Hi Vesa,
>
> > I think it would be wise to keep some kind of status updates from time
> > to time so we can keep track on what people are doing (related to grub
> > 2). If we continue with current situation we are long in 2010's before
> > we have next release.
>
> Agreed, we should head to he next release now.
>
> > I think it would also be important to coordinate more different
> > activities within grub 2. In example graphical menu has been issue for
> > several years now :). Therefore I would propose that we would setup a
> > group of people that would concentrate on specific issues related to
> > implmentation (like a work group or something). I do not see it as a
> > requirement that this group of people would implement the feature
> > (though that would be good), but most importantly to draft out how
> > features should work. When there is a spec written how feature should
> > work then it would be much easier to implement that feature and then it
> > would match ideology of other relevant developers (eg. to get patch
> > accepted).
>
> Right, it's a big problem that people send in patches that do not
> match what we had in mind.  Writing down things can prevent such
> problems.  We can use the wiki for that.  But in the longer term we
> need something with more structure.
>
> > I would see that at least following working groups should be formed. Of
> > course we could tackle design issue at a time and then move to other
> issues.
> >
> > - Graphical menu (needs API spec, configuration file specs, guidelines
> > for implementation, information how to integrate with scripting)
> >
> > - Network support (needs API spec, driver architecture, protocol stacks,
> > file system support)
>
> Actually, I thought a lot about networking.  I even have some code.
>
> As you know I will be working on ffmpeg during the summer.  I will try
> to free some evenings and weekends for GRUB 2 work.  In that time I
> will try to finish scripting support and networking.
>
> > Perhaps some others too... (please add)
>
> People worked on all kinds of ports.  Some patches have not been
> committed and suffer from bit rot.  The main problems were that the
> maintainers didn't have much time lately and the patches were big huge
> chunks of code.
>
> Something I think is important for GRUB 2 is regression testing.  So
> we can make sure things like scripting works, filesystems work
> correctly, etc.
>
> Another thing is the PPC port.  We need a macos loader.  It is high
> priority if we want to replace yaboot.
>
> > Anyway. First of all I would like to hear if you are developing
> > something above or something else, reply this e-mail and tell us about
> > it, there is no reason that work should be duplicated. Especially if you
> > are already developing a feature your words would be good to be heard.
> > If you are just reporting back list of stuff you are working on, please
> > keep list as simple and clean as we want only big picture :). You could
> > also describe how are you progressing with the feature.
>
> Well, if people want to work on scripting or networking they should
> talk to me.  I have lots of code on my hd that is incomplete or just
> not cleaned up.  It would be a waste of time if it were rewritten.
> And please poke me a lot to get me to work... ;)



I am interested on Networking. Please tell me your suggestion.


Ashok






> Ideas are welcome where to store this information are also welcome :).
> > We would need to track requirements for features on component level.
> > More automated the better.
>
> Something like savannah.  Okuji doesn't like savannah that much,
> IIRC.  And I don't either.  But I agree that too much goes wrong to
> keep on working this way.
>
> --
> Marco
>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>

[-- Attachment #2: Type: text/html, Size: 5028 bytes --]

Re: status update for grub 2 developments?

[adrian15]

Bean escribió:
>> Well, if people want to work on scripting or networking they should
>> talk to me.  I have lots of code on my hd that is incomplete or just
>> not cleaned up.  It would be a waste of time if it were rewritten.
>> And please poke me a lot to get me to work... ;)
> 
> I'm interested in scripting. What could I do to help you ?

	As long as you may re-read Marco_g source code you can try to fix a bug
that I have found I suppose in the parser.

	If you type any command with a \ character not being inside " "
characters it gives an grub internal error.

	echo "\n"		--> OK
	echo \n fff 		--> GRUB INTERNAL ERROR

adrian15

Re: status update for grub 2 developments?

[Marco Gerards]

Bean <bean123@126.com> writes:

> On Sun, Jun 24, 2007 at 12:22:18PM +0800, Bean wrote:
>> Some bugs I found on scripting.
>> 
>> 1. token parser
>> 
>> echo aa"bb"
>> aabb
>> (correct)
>> 
>> echo aa"bb"cc
>> aabb
>> (cc is lost)
>> 
>> echo aa$prefix
>> aa (hd0,1)/boot/grub
>> (should be one token)
>> 
>> echo $prefix/grub.cfg
>> (hd0,1)/boot/grub /grub.cfg
>> (should be one token)
>> 
>> The problem here is that when a variable is mixed with text, the token breaks.
>> I think this is also the reason why set doesn't work with variable.

Yes, this is a problem in the parser.

>> set AA=1
>> set BB=$AA
>> 
>> will expand to
>> 
>> set AA=1
>> set BB= 1
>> 
>> Thereforce the value of BB is empty instead of 1.
>> 
>
> I fix the token parser problem, changes include:
>
> 1. Inside grub_script_yylex2, mixed text is detected, and transformed into
> arg structure instead of text.

Can you please explain how this works?  This sounds like enforcing
parser policies on the lexer.  I don't like this, because in that case
the structure would be lost.  Actually, this can and should be fixed
in the parser or properly in the lexer.

If you want to solve this in the lexer, the lexer shouldn't release a
token when a "" is encountered.

The current lexer really sucks.  Does someone know of a good lexer
generator other than flex?  Flex depends on libc :-(.  That's the
reason we have this damn ugly lexer now...

> 2. Fix a small bug that cause trash output when an undefine variable is
> referenced.
>
> 3. Close varible definition when / is encountered.
>
> With this patch, the following command works properly:
>
> echo aa"BB"cc
> aaBBcc
>
> set AA=1
> set BB=$AA
> echo $BB
> 1
>
> echo $prefix/grub.cfg
> (hd0,1)/boot/grub/grub.cfg
>
> echo ${prefix}/grub.cfg
> (hd0,1)/boot/grub/grub.cfg
>
> set AA=1
> echo aa"$AA"bb
> aa1bb
>
> echo aa${?}bb
> aa0bb

Great :-)

> -- 
> Bean <bean123@126.com>
>
> 2007-06-24  Bean  <bean123@126.com>
>
> 	* kern/parser.c (state_transitions): Add new case.

Which case?

btw, please use "diff -up" ;-)

> 	* normal/execute.c (grub_script_argument_to_string):
> 	Output empty string when variable does not exist.
>
> 	* normal/lexer.c (grub_script_yylex2): Handle mixed text
> 	properly.
>
> 	* normal/parser.y : token GRUB_PARSER_TOKEN_VAR returns arg
> 	instead of text.
>
>
> Index: kern/parser.c
> ===================================================================
> RCS file: /sources/grub/grub2/kern/parser.c,v
> retrieving revision 1.2
> diff -u -r1.2 parser.c
> --- kern/parser.c	23 Nov 2005 03:36:24 -0000	1.2
> +++ kern/parser.c	24 Jun 2007 11:23:48 -0000
> @@ -44,6 +44,7 @@
>    { GRUB_PARSER_STATE_VAR, GRUB_PARSER_STATE_VARNAME2, '{', 0},
>    { GRUB_PARSER_STATE_VAR, GRUB_PARSER_STATE_VARNAME, 0, 1},
>    { GRUB_PARSER_STATE_VARNAME, GRUB_PARSER_STATE_TEXT, ' ', 1},
> +  { GRUB_PARSER_STATE_VARNAME, GRUB_PARSER_STATE_TEXT, '/', 1},
>    { GRUB_PARSER_STATE_VARNAME2, GRUB_PARSER_STATE_TEXT, '}', 0},

Which bug does this solve?
  
>    { GRUB_PARSER_STATE_QVAR, GRUB_PARSER_STATE_QVARNAME2, '{', 0},
> Index: normal/execute.c
> ===================================================================
> RCS file: /sources/grub/grub2/normal/execute.c,v
> retrieving revision 1.4
> diff -u -r1.4 execute.c
> --- normal/execute.c	28 May 2006 21:58:34 -0000	1.4
> +++ normal/execute.c	24 Jun 2007 11:23:48 -0000
> @@ -50,7 +50,8 @@
>        if (argi->type == 1)
>  	{
>  	  val = grub_env_get (argi->str);
> -	  size += grub_strlen (val);
> +	  if (val)
> +	    size += grub_strlen (val);

Good one :-)

>  	}
>        else
>  	size += grub_strlen (argi->str);
> @@ -68,7 +69,8 @@
>        if (argi->type == 1)
>  	{
>  	  val = grub_env_get (argi->str);
> -	  grub_strcat (chararg, val);
> +	  if (val)
> +	    grub_strcat (chararg, val);
>  	}

:-)

>        else
>  	grub_strcat (chararg, argi->str);
> Index: normal/lexer.c
> ===================================================================
> RCS file: /sources/grub/grub2/normal/lexer.c,v
> retrieving revision 1.6
> diff -u -r1.6 lexer.c
> --- normal/lexer.c	4 Jun 2006 15:56:55 -0000	1.6
> +++ normal/lexer.c	24 Jun 2007 11:23:48 -0000
> @@ -50,7 +50,7 @@
>    struct grub_lexer_param *param;
>  
>    param = grub_malloc (sizeof (*param));
> -  if (! param)
> +  if (!param)
>      return 0;

Please don't do this...
  
>    param->state = GRUB_PARSER_STATE_TEXT;
> @@ -100,7 +100,7 @@
>        if (state->recording[--state->recordpos] != '}')
>  	{
>  	  grub_printf ("Internal error while parsing menu entry");
> -	  for (;;); /* XXX */
> +	  for (;;);		/* XXX */

Can you leave this out the patch?

>  	}
>        state->recording[state->recordpos] = '\0';
>      }
> @@ -118,7 +118,7 @@
>        char *old = state->recording;
>        state->recordlen += 100;
>        state->recording = grub_realloc (state->recording, state->recordlen);
> -      if (! state->recording)
> +      if (!state->recording)

Same here.

>  	{
>  	  grub_free (old);
>  	  state->record = 0;
> @@ -137,10 +137,10 @@
>  }
>  
>  int
> -grub_script_yylex2 (YYSTYPE *yylval, struct grub_parser_param *parsestate);
> +grub_script_yylex2 (YYSTYPE * yylval, struct grub_parser_param *parsestate);

Can you leave this out?
  
>  int
> -grub_script_yylex (YYSTYPE *yylval, struct grub_parser_param *parsestate)
> +grub_script_yylex (YYSTYPE * yylval, struct grub_parser_param *parsestate)

Same here.

>  {
>    int r = -1;
>  
> @@ -154,31 +154,32 @@
>  }
>  
>  int
> -grub_script_yylex2 (YYSTYPE *yylval, struct grub_parser_param *parsestate)
> +grub_script_yylex2 (YYSTYPE * yylval, struct grub_parser_param *parsestate)
>  {
>    grub_parser_state_t newstate;
>    char use;
>    char *buffer;
>    char *bp;
>    struct grub_lexer_param *state = parsestate->lexerstate;
> +  struct grub_script_arg *arg = 0;
> +  int done = 0;
>  
>    if (state->done)
>      return 0;
>  
> -  if (! *state->script)
> +  if (!*state->script)

Please leave this out.

>      {
>        /* Check if more tokens are requested by the parser.  */
>        if ((state->refs
> -	   || state->state == GRUB_PARSER_STATE_ESC)
> -	  && state->getline)
> +	   || state->state == GRUB_PARSER_STATE_ESC) && state->getline)
>  	{
> -	  while (!state->script || ! grub_strlen (state->script))
> +	  while (!state->script || !grub_strlen (state->script))
>  	    {
>  	      grub_free (state->newscript);
>  	      state->newscript = 0;
>  	      state->getline (&state->newscript);
>  	      state->script = state->newscript;
> -	      if (! state->script)
> +	      if (!state->script)
>  		return 0;
>  	    }
>  	  grub_dprintf ("scripting", "token=`\\n'\n");
> @@ -196,163 +197,192 @@
>  	}
>      }
>  
> -  newstate = grub_parser_cmdline_state (state->state, *state->script, &use);
> -
> -  /* Check if it is a text.  */
> -  if (check_textstate (newstate))
> +  while (1)

Can you please split up the code after this, so the changes unrelated
to the argument parsing are still there.  I am not sure what to do
with the argument parsing part yet.  While I do certainly like the
other changes.  This code is hard to review if both changes are
interleaved.

> Index: normal/parser.y
> ===================================================================
> RCS file: /sources/grub/grub2/normal/parser.y,v
> retrieving revision 1.6
> diff -u -r1.6 parser.y
> --- normal/parser.y	4 Jun 2006 15:56:55 -0000	1.6
> +++ normal/parser.y	24 Jun 2007 11:23:48 -0000
> @@ -46,9 +46,9 @@
>  %token GRUB_PARSER_TOKEN_VAR
>  %type <cmd> script grubcmd command commands commandblock menuentry if
>  %type <arglist> arguments;
> -%type <arg> argument;
> +%type <arg> argument GRUB_PARSER_TOKEN_VAR;

I still have my doubts on this.  Actually, I will try to look into the
parser myself to see what needs to be done precisely.

>  %type <string> "if" "while" "function" "else" "then" "fi"
> -%type <string> text GRUB_PARSER_TOKEN_NAME GRUB_PARSER_TOKEN_VAR
> +%type <string> text GRUB_PARSER_TOKEN_NAME
>  
>  %pure-parser
>  %lex-param { struct grub_parser_param *state };
> @@ -86,7 +86,7 @@
>     for example: `foo${bar}baz'.  */
>  argument:	GRUB_PARSER_TOKEN_VAR
>  		  {
> -		    $$ = grub_script_arg_add (state, 0, GRUB_SCRIPT_ARG_TYPE_VAR, $1);
> +		    $$ = $1;
>  		  }

Same here, of course.

--
Marco

Re: status update for grub 2 developments?

[Marco Gerards]

"Ashok kumar" <ashok.grubdev@gmail.com> writes:

[...]

>> Well, if people want to work on scripting or networking they should
>> talk to me.  I have lots of code on my hd that is incomplete or just
>> not cleaned up.  It would be a waste of time if it were rewritten.
>> And please poke me a lot to get me to work... ;)
>
> I am interested on Networking. Please tell me your suggestion.

Please see the code I just sent to the list.  More to come.

--
Marco