From: Marco Gerards <metgerards@student.han.nl>
To: grub-devel@gnu.org
Subject: Scripting support
Date: Sat, 22 Oct 2005 15:59:05 +0200 [thread overview]
Message-ID: <87pspxtzyu.fsf@student.han.nl> (raw)
Hi,
Last days I have been thinking about scripting support. With my last
patch it should be easy to implement. I hope Vladimir is still
interested in this.
The most important is the general design. I think we shouldn't put
too much in the core and not even in normal mode. This is the same
approach bash has taken. I think the core functionality should be:
- variables (we have that)
- functions
Functions should work *exactly* like normal GRUB commands. In
that case we can easily mix GRUB commands and functions.
- Return values
All commands should be able to return a value. That's also what
bash has. This value can be stored in a variable or simply
returned, I am not too sure about that. Just check what bash
does.
- Conditional statements like if and case
- loops: until, while and for
Whenever a command line should be executed or when a script file is
executed, it's the same. The block of code is just parsed and
executed by a function (the parser, I guess :)).
It's important to see that GRUB does not do anything like
calculations. All this can be moved into a command. When making a
bash script you have the same, there is the expr command. So we have
to keep the core functionality minimal and should offer the commands
in command/ like we do now.
First the lexer. I think it should work like this:
normal/parser.c should contain the lexer. The prototypes etc. can
just be added to include/grub/parser.h.
There are just a few tokens we have to recognize. Think about stuff
like a string of text, if, elif, case, ;, [], etc.
The parser can be quite simple. It has to support all kinds of loops,
etc. I am not sure how to deal with that. perhaps we have to feed
the block within a for loop (for example) to the parser until the for
loop exits. Another possibility is creating some kind of P-code and
parse that later on. I wonder what the best approach is.
For the parser we should use bison, I think. Writing a handwritten
parser is acceptable if some standard approach is taken and it's
really really clean and well documented.
Any idea is welcome. I hope we can discuss the implementation in
detail so we can have scripting support soon.
Thanks,
Marco
next reply other threads:[~2005-10-22 13:59 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-22 13:59 Marco Gerards [this message]
2005-10-22 14:46 ` Scripting support Vladimir Serbinenko
2005-10-22 15:08 ` Marco Gerards
2005-10-22 15:37 ` Vladimir Serbinenko
2005-10-22 15:47 ` Marco Gerards
2005-10-22 16:03 ` Vladimir Serbinenko
2005-10-22 16:42 ` Marco Gerards
2005-10-22 16:33 ` Marco Gerards
2005-10-28 3:04 ` Yoshinori K. Okuji
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=87pspxtzyu.fsf@student.han.nl \
--to=metgerards@student.han.nl \
--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.