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