From: "Yoshinori K. Okuji" <okuji@enbug.org>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: Pre-alpha scripting engine
Date: Thu, 20 Jan 2005 18:56:47 +0100 [thread overview]
Message-ID: <200501201856.47799.okuji@enbug.org> (raw)
In-Reply-To: <41EFE5F9.2020202@list.ru>
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
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.
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.
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.
Okuji
next prev parent reply other threads:[~2005-01-20 18:26 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 [this message]
2005-01-20 18:34 ` Serbinenko Vladimir
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=200501201856.47799.okuji@enbug.org \
--to=okuji@enbug.org \
--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.