grub2 file browser draft

grub2 file browser draft

[adrian15]

Marco Gerards you asked me the other day about scripting. If there was 
something missing or any other thing that he could do.

This draft about a grub2 file draft can help him thinking about how 
powerful is his scripting or not.


The user sees inside a menu:
Floppy1
Floppy2
HardDisk1
HardDisk2

He selects HardDisk1. He sees another menu:
	View
	Save as Argument 1
	Save as Argument 2
	Setup Grub Here
	This is Grub Root (Only if the hard disk/device has no partitions)
He selects View. He sees another menu:
	hda1
	hda2
	hda3
	hda4
	hda5
He selects hda1. He sees another menu:
	View
	Save as Argument 1
	Save as Argument 2
	Setup Grub Here
	This is Grub Root (Only if partition filesystem is grub readable)
He selects View. He sees another menu:
	/boot
	/etc
	/var
He selects /etc. He sees another menu:
	View
	Save as Argument 1
	Save as Argument 2
He selects View. He sees another menu:
	fstab
	config1
	config2
He select fstab. He sees another menu:
	View
	Save as Argument 1
	Save as Argument 2
Let's say he returns to previous menu where he is seeing /etc folder.
He select my_index.html. He sees another menu:
	View inside a web browser (GRUB2 will have a module with basic html 
reading I suppose)
	View
	Save as Argument 1
	Save as Argument 2
	
So Marco Gerards....
Do you think that this can be done with your grub scripting? Or the 
grub2 scripting needs more hacking?

adrian15

Re: grub2 file browser draft

[Marco Gerards]

adrian15 <adrian15@raulete.net> writes:

Hi Adrian,

> Marco Gerards you asked me the other day about scripting. If there was
> something missing or any other thing that he could do.
>
> This draft about a grub2 file draft can help him thinking about how
> powerful is his scripting or not.

Some of these things are possible (like using variables, etc).  Other
things are not possible yet.  One of the most import (at least for
you!) missing constructs is the `for' which can be used to iterate
over files in bash.

I noticed you mention hda1 here, which is a Linux device name.  I have
explained you before it is technically not possible to translate GRUB
device names to Linux device names.  I wish it was possible, but
unfortunately it currently isn't because the BIOS is used to access
harddisks.

Here are some things I would like to work on:

- Error handling.  It should become very clear how errors are dealt
  with from scripts.

- The `for' loop.  This is useful in some cases, for example to
  automatically include files, to generate menu entries, etc, etc.

- Generating menu entries.  My plan is to make it possible to create
  templates over which you can iterate.  I will explain this another
  time in detail.

- Completing/rewriting the test command (which I almost finished, btw).

- Documentation.  This is the most important thing that is currently
  lacking.  I will soon write a document that describes the current
  functionality and the functionality I plan to implement.  This is
  important for people who like to test all this, but more
  importantly: it gives fellow developers the chance to influence what
  I am doing, criticize it and to take part in the discussion about
  the syntax.

- Adding random features and bug fixing.

The documentation will come within a few weeks (or days, who
knows...).  It's important to me and other people that these features
can and will be discussed.

--
Marco

Re: grub2 file browser draft

[adrian15]

> I noticed you mention hda1 here, which is a Linux device name.  I have
> explained you before it is technically not possible to translate GRUB
> device names to Linux device names.  I wish it was possible, but
> unfortunately it currently isn't because the BIOS is used to access
> harddisks.

I am sorry, I did not want to start over the discussion. I just wanted 
to know if given a hard disk device we could iterate over its partitions 
or at least generate a menu from them.

I've seen that you say we cannot iterate over files so I supose that it 
also means that we cannot iterate over partitions yet.

adrian15

Re: grub2 file browser draft

[Marco Gerards]

adrian15 <adrian15@raulete.net> writes:

>> I noticed you mention hda1 here, which is a Linux device name.  I have
>> explained you before it is technically not possible to translate GRUB
>> device names to Linux device names.  I wish it was possible, but
>> unfortunately it currently isn't because the BIOS is used to access
>> harddisks.
>
> I am sorry, I did not want to start over the discussion. I just wanted
> to know if given a hard disk device we could iterate over its
> partitions or at least generate a menu from them.
>
> I've seen that you say we cannot iterate over files so I supose that
> it also means that we cannot iterate over partitions yet.

Please read my other email about scripting.  I assume all your
possible questions are answered there, otherwise please ask.

--
Marco

Re: Scripting (IMPORTANT!)

[adrian15]

> Hi,
> - root: The active disk/partition (rw, global)
> - prefix: The pathname used to load grub.cfg and the modules (rw, global)
> - platform: Set to the platform, eg. EFI, IEEE1275, PCBIOS, etc. (ro, global)
> - processor: Processor architecture GRUB was compiled for, eg. PPC, x86 (ro, global).
> - debug: Print debugging messages for certain parts of the code, or
>   all messages when set to all.  (rw, global?)
> - pager: When set to `1', wait for a key when the bottom of the screen was reached.

Marco, my problems comes when I want to load with configfile and source 
many files from a grub2 cdrom. I just want to make sure that I am 
loading from the cdrom but not from another place.

Currently I use something like this in SGD:

configfile $(grub_device)/my_folder/myfile.lst

$(grub_device) is a variable that stores (cd), (fd0) or (hd0) depending 
from which place has SGD booted.

Let's suppose that you can change grub2's root variable with the ROOTC 
command (I do not know which it is the legacy's root equivalent in 
grub2, I will name it ROOTC in order to distinguish it from the variable).
Let's see an example. You boot from a cd. root is (cd). Then you select 
a menu that loads a configfile file from the hard disk. So root is 
changed to (hd0,0). Ok...

If there is an error and want to come back to my menues... How can I 
change the root variable back so that something as:

configfile ${root}/my_folder/myfile.lst

works as expected (loading a file from the cdrom not from the hard disk).

CONCLUSION: I would add a grub_device or first_boot_device variable.

> function funcname { code }
 > if command ; then commands fi
 > for x in (*) ; do commands ; done

A question arises to me... Do we have to type this commands in a single 
line or can we write them in multiple lines?


> Arguments can be passed to functions.  In the function body they can
> be accessed as in bash ($1, $2, etc).

I do not know why this should be useful... but would $0 return the name 
of the function?

> ==> Idea: Exporting functions to be full featured commands that can be
>     tab completed, documented, etc.  This way functions can be
>     implemented by scripts instead of C code.
Yes, please. If I need a more complex search command, I will need to 
implement it as a function and thus I will use it in a lot of scripts 
and exporting it would be a good idea.

> ============
> Menu entries
> ============
> ==> Discussion: Perhaps I will change the #1 into $1, although this is
>     not really a variable.
This is interesting. If I was myself coding I will choose the #1 syntax. 
However I suppose that people will get used to the $1 and will 
understand better the $1 syntax. I think it is better the $1 syntax.

However, let's see a problematic example.

function boot_linux_part_menu_gen {

begins loop that sets i = 1...x
@ "Partition $i" $i { linux /vmlinuz root=/dev/hda#{1} }
ends loop that sets i = 1...x

}

Sorry... Let's use the another syntax...

function boot_linux_part_menu_gen {

begins loop that sets i = 1...x
@ "Partition $i" $i { linux /vmlinuz root=/dev/hda${1} }
ends loop that sets i = 1...x

}

VOILA... ${1} refers to the boot_linux_part_menu_gen function first 
argument or to the Partition mennu first argument ?

My final vote is for the #{1} syntax for the sake of simplicity.

> Iterating over files:
> for x in (hd0,3)/foo/* ; do commands ; done

I think we need an start variable and a max variable for generating 
menus from big folders.

I do not know which it is the number of files of /etc folder in linux 
folders but I think it is very big.

The idea is with a start=0 show 20 files (like search engines) in a menu 
and the last entry calls the same menu generator function with the:
start=20 show 20 files argument so that we can see the next 20 files.

This will remove memory-eating problems I think.

> foreach x in files ; do commands ; done

I would improve this like this:

foreach x in files ($folder) ; do commands ; done
> From: Johan Rydberg 
> What about a 'prompt' variable?

I think that fits into the cd and pwd discussion that M. Gerards wanted 
to start.

In my opinnion there should be a pwd variable for each of the scopes of 
grub.

By the way...

I configfile one.cfg
 From one.cfg I source two.cfg.
Then from two.cfg I configfile three.cfg.
Then from the three.cfg the hipotetical exit command is run do we return 
to the middle of one.cfg execution or not ?

A question... Will I be able to use relative paths (./, ../path/)at last?

adrian15

Re: Scripting (IMPORTANT!)

[Marco Gerards]

adrian15 <adrian15@raulete.net> writes:

Hi,

> Marco, my problems comes when I want to load with configfile and
> source many files from a grub2 cdrom. I just want to make sure that I
> am loading from the cdrom but not from another place.
>
> Currently I use something like this in SGD:
>
> configfile $(grub_device)/my_folder/myfile.lst
>
> $(grub_device) is a variable that stores (cd), (fd0) or (hd0)
> depending from which place has SGD booted.
>
> Let's suppose that you can change grub2's root variable with the ROOTC
> command (I do not know which it is the legacy's root equivalent in
> grub2, I will name it ROOTC in order to distinguish it from the
> variable).

In GRUB 2 root is a variable which you can change like any other
variable, no need to use a command.

> Let's see an example. You boot from a cd. root is (cd). Then you
> select a menu that loads a configfile file from the hard disk. So root
> is changed to (hd0,0). Ok...

Why would root be changed by this?  Because the configuration file
does this?

> If there is an error and want to come back to my menues... How can I
> change the root variable back so that something as:
>
> configfile ${root}/my_folder/myfile.lst
>
> works as expected (loading a file from the cdrom not from the hard disk).
>
> CONCLUSION: I would add a grub_device or first_boot_device variable.

I see the problem, but draw a different conclusion.  Either root
should not be an exported variable (which can cause other problems),
or you have to use temporary variables which means GRUB 2 does not
have to be changed.

>> function funcname { code }
>> if command ; then commands fi
>> for x in (*) ; do commands ; done
>
> A question arises to me... Do we have to type this commands in a
> single line or can we write them in multiple lines?

It's possible to use multiple lines.

>> Arguments can be passed to functions.  In the function body they can
>> be accessed as in bash ($1, $2, etc).
>
> I do not know why this should be useful... but would $0 return the
> name of the function?

Yes.

>> ==> Idea: Exporting functions to be full featured commands that can be
>>     tab completed, documented, etc.  This way functions can be
>>     implemented by scripts instead of C code.
> Yes, please. If I need a more complex search command, I will need to
> implement it as a function and thus I will use it in a lot of scripts
> and exporting it would be a good idea.

Well, exporting here means that it will be integrated fully.  It
doesn't mean that if it is not exported, it will not be available.
The difference is that when you export it, or transform it to a
command it will be fancy.  In that case the function HAS TO DO
argument parsing, export help texts, etc.  I don't think you will
really need this.

[...]

> VOILA... ${1} refers to the boot_linux_part_menu_gen function first
> argument or to the Partition mennu first argument ?

In that case the one for the menu entry.

>> Iterating over files:
>> for x in (hd0,3)/foo/* ; do commands ; done
>
> I think we need an start variable and a max variable for generating
> menus from big folders.

You can better solve this using `if'.  I think we also need the `expr'
command, which I will add to my todo.  In that case you can just count
and break out of the loop when you are done.  I will have a look how
one would do this when using bash.

> By the way...
>
> I configfile one.cfg
> From one.cfg I source two.cfg.
> Then from two.cfg I configfile three.cfg.
> Then from the three.cfg the hipotetical exit command is run do we
> return to the middle of one.cfg execution or not ?

Yes.

> A question... Will I be able to use relative paths (./, ../path/)at last?

This is implemented already, IIRC.  Why wouldn't this work?  The . and
.. are just regular directory entries.  In some filesystems like the
iso9660 filesystem I just "simulate" them.

--
Marco