All of lore.kernel.org
 help / color / mirror / Atom feed
From: Serbinenko Vladimir <serbinenko.vova@list.ru>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: Pre-alpha scripting engine
Date: Thu, 20 Jan 2005 19:34:17 +0100	[thread overview]
Message-ID: <41EFF9A9.5080109@list.ru> (raw)
In-Reply-To: <200501201856.47799.okuji@enbug.org>

Yoshinori K. Okuji wrote:

>On Thursday 20 January 2005 18:10, Serbinenko Vladimir wrote:
>  
>
>>The problem with guile is that it has no $ before variable which
>>makes it difficult to integrate with shell. I discovered that bash
>>and PHP can even coexist!!
>>    
>>
>
>As I said, Lisp is not good, because it is too difficult to use on the 
>command-line interface. But I don't know if PHP is easy to use on it. I 
>used PHP many years ago, but I forget it.
>
>  
>
>>But I don't know bash very well so if I'm wrong please e-mail it. Now
>>I'm rewriting the parser for easier integrating(thanks Marco).
>>    
>>
>
>There are many differences. The critical point is that you cannot write 
>this in PHP:
>
>kernel /boot/vmlinuz root=/dev/hda1
>  
>
Normally not but it's easy to extend it

>This is not a valid expression in PHP. If you want to do the same in 
>PHP, it could look like this:
>
>kernel("/boot/vmlinuz", "root=/dev/hda1")
>
>As I mentioned in the previous mail, I don't think it is a good idea to 
>have multiple languages. So the important question here is if you want 
>to use PHP on the command-line interface or not. I suspect that this is 
>not feasible.
>
>  
>
Imho multiple languages will just wasting of time. As a matter of fact 
my prevous letter was just some thoughts

>If your intention is to make your scripting engine standard in GRUB, I'd 
>recommend considering what you really want to do with a scripting 
>language under GRUB. IIRC, you haven't described what your motivation 
>is.
>
>  
>
My motivation is an automatisation of booting e.g. run different 
commands depending on circumstances (time, system crash, wake-on-..., 
undoing booting preparation(hide,unhide,...))

>I think the choice of a scripting language depends on what we really 
>want to address. In other words, what do we want to define as the scope 
>of a scripting language? Do we want to remove C code as much as 
>possible, or, do we want to have a merely preprocessor? It is not a new 
>idea to have a scripting language to make low-level functions (suppose 
>Forth on Open Firmware), but I doubt if this is worth doing, because 
>writing an interpreter can be more complex than writing device drivers.
>
>  
>
I think that low-level scripting language will be an error but perhaps 
some easy scripts like running cmp with MBR and file parsing its output 
and pausing booting if difference detected

>Okuji
>
>  
>
So I'm waiting for your decision about language. But after all now I 
think that bash will be good idea

>_______________________________________________
>Grub-devel mailing list
>Grub-devel@gnu.org
>http://lists.gnu.org/mailman/listinfo/grub-devel
>
>
>  
>




  reply	other threads:[~2005-01-20 19:03 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <E1CpUhp-000IYX-00.grub-devel-bounces+serbinenko-vova=list-ru-gnu-org@mx11.mail.ru>
2005-01-14 18:48 ` Pre-alpha scripting engine Serbinenko Vladimir
2005-01-18 18:55   ` Marco Gerards
2005-01-18 19:54     ` Serbinenko Vladimir
2005-01-19 13:01       ` Marco Gerards
2005-01-19 20:04         ` Yoshinori K. Okuji
2005-01-19 20:48           ` Marco Gerards
2005-01-19 21:48             ` Maurizio Boriani
2005-01-20 17:10               ` Serbinenko Vladimir
2005-01-20 17:56                 ` Yoshinori K. Okuji
2005-01-20 18:34                   ` Serbinenko Vladimir [this message]
2005-01-21  2:26                     ` Hollis Blanchard
2005-01-21 17:23                       ` Scripting, partitions and filesystems Serbinenko Vladimir
2005-01-21 17:52                       ` Device syntax, scripting, " Serbinenko Vladimir
2005-01-23 14:22                     ` Pre-alpha scripting engine Yoshinori K. Okuji
2005-01-19 20:59           ` Tomas Ebenlendr

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=41EFF9A9.5080109@list.ru \
    --to=serbinenko.vova@list.ru \
    --cc=grub-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.