[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Scripting (IMPORTANT!)

From: adrian15
Subject: Re: Scripting (IMPORTANT!)
Date: Fri, 06 Oct 2006 09:50:01 +0200
User-agent: Thunderbird (X11/20060808)

- 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, 
- 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 

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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]