Re: Scripting (IMPORTANT!)

[Marco Gerards]

adrian15 <address@hidden> 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