Re: String functions

[Arbiel Perlacremaz]

Thank you very much for all this.

Le 03/04/2012 00:15, Jordan Uggla a écrit :
> Please keep help-grub CCd so that others can benefit from the conversation.
This come from the fact that I'm used to use the "answer" icon of 
Thunderbird, and this icon corresponds to "answer to sender" and not to 
"answer to everybody". I've got to try to change it, or to insert a 
second icon in the menu bar.
> On Mon, Apr 2, 2012 at 4:03 AM, Arbiel Perlacremaz
> <address@hidden>  wrote:
> > > regexp --set=drive "(.*)," "$root"
> > I'll try it, even if I don't really understand the command
> The --set=drive option says that the result should be stored in the
> variable $drive, the "(.*)," is a regular expression. If it were just
> ".*," then it would be more clear that it's matching any characters
> which come before a ',' (comma) character. The parentheses around the
> '.*' indicate that that's what we want to capture  (we don't want the
> ',' at the end). This is all standard regular expression syntax. The
> last option is the string that we're using the regexp to manipulate,
> our input string. In my example I used "$root", but you can have
> regexp read from any variable you want, and search write to any
> variable you want so you could do 'search --set=drive_and_partition
> --fs-uuid UUID_HERE;  regexp --set=drive "(.*),"
> "$drive_and_partition" '.
>
> > As an exemple, let's suppose I have got a directory with some .iso files and
> > a second directory with Grub configuration files. These configuration files
> > countain menuentries for booting the PC with the .iso files. But I may have
> > more iso than cfg files, or conversely, more cfg than iso files.
> First, I would check if the iso files you're using already contain a
> loopback.cfg, or if they're iso files you're generating yourself you
> might want to consider adding a loobpack.cfg to them :
> http://www.supergrubdisk.org/wiki/Loopback.cfg.
I'm using the loopback.cfg file when it exists. However, in that case, 
its location into the iso file has not been standardize, i.e. it isn't 
always into the /boot/grub directory. In that later case, I am writing a 
loopback.cfg file of my own. So, my *.cfg files into the cfg files 
directory are either a copy of the iso's loopback.cfg or my own file.
> > I would be glad to be able to generated a "loopback ... file.iso" and a
> > "source .... file.cfg" if and only if both files, file.iso and file.cfg
> > exist in their respective directories. For doing that, I suppose I can loop
> > on the file names found in a directory, let's say the iso directory, and
> > then lookup into the cfg directory to check for the cfg file, after having
> > substituted "iso" for "cfg" in the file name.
> Let's assume that the directories are "/boot-isos/" for the iso files
> and "/boot-cfgs/" for the grub.cfg files. Then you could do something
> like this:
>
>
> insmod regexp # Needed to allow the use of globs.
>
> for iso in /boot-isos/*.iso; do
>    # $stripped_name is the name of the iso with the path and extension
> stripped away
>    regexp --set=stripped_name '^/boot-isos/(.*)\.iso$' "$iso"
>
>    cfg="/boot-cfgs/${stripped_name}.cfg"
>
>    # If a file exists at the path contained in $cfg
>    if [ -e "$cfg" ]; then
>      source "$cfg"
>    fi
> done
>
> > I don't know yet exactly which code I should write, maybe an "empty"
> > menuentry and then use Grub's chosen variable to have only one "loopback" et
> > one "source" command, or a succession of "loopbck" and "source" statements.
> I'm not sure if I understand correctly, but if you're asking what your
> .cfg files corresponding to each iso file should look like, I would
> say that they should either contain simple literal menu entry commands
> like
The issue is the following : I don't know yet (I haven't tested yet) 
whether I can intertwine loopback statements into the menuentry 
statements, such as
loopback loop file1.iso
source file1.cfg (the menu entries)
loopback loop file2.iso
source file2.cfg

> menuentry "GenBuntu" {
>    loopback loop /boot-isos/grml.iso
>
>    linux (loop)/vmlinuz some kernel arguments here
>    initrd (loop)/initrd
>
>    loopback --delete loop
> }
>
> Or if you want them to be slightly more flexible, so that the path to
> the iso isn't hard coded, you can use the the $iso variable from the
> earlier code (the for loop) (since this code is being sourced it can
> access (and modify, so be careful) any variables from the context it
> was sourced from). for example:
>
> menuentry "GenBuntu (${iso})" {
>    loopback loop "$iso"
>
>    linux (loop)/vmlinuz some kernel arguments here
>    initrd (loop)/initrd
>
>    loopback --delete loop
> }
Let me tell you what. My aim in doing that is the following.

I'm convinced we (GNU/Linux promotors) have a to complex approach for 
Microsoft-to-GNU/Linux potential migrators. To install their first 
distribution they have to learn how to partition their disk, the have to 
get accustomed to Grub, they have to burn a CD, or the generate a 
bootable USB key. That's a lot for people who have been kept in the dark 
for sometimes many years, and generally do not desire to become "geeks", 
as they name us. They get afraid, and too often, to my opinion, drop 
before entering the game

To have a smoother approach, I believe you can play as follows:
1) from a "protected" web page (protected so as not to get modified into 
a malicious page) replace their Windows bootloader by Grub, create on 
their FAT or NTFS system partition a /boot/grub directory with all 
necessary files, generate a grub.cfg file with a single menuentry to 
boot into their Windows system (all this works, I have tested it)
2) let them see by themselves that they still have their system runnnig, 
and that nothing malicious has been made to their PC
3) from another "protected" web page, have them download one of several 
distributions to check, and record the appropriate loopback.cfg files, 
to be included in their Grub menu
4) boot into any one of these distributions, without having done 
anything else but download the iso files, no CD burning, no USB-key 
Unetbooting, no Wubi installing

Then, when they are ready, they will be more comfortable in 
partitionning their hard disk and hard installing their first distribution