From: Marco Gerards <metgerards@student.han.nl>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: Scripting support (PATCH)
Date: Sun, 30 Oct 2005 22:04:22 +0100 [thread overview]
Message-ID: <871x22hg2x.fsf@student.han.nl> (raw)
In-Reply-To: <b4542374deb047c7c0060bbbb552d4a2@penguinppc.org> (Hollis Blanchard's message of "Sun, 30 Oct 2005 14:49:31 -0600")
Hollis Blanchard <hollis@penguinppc.org> writes:
> I don't have many comments, since I'm not familiar with lexing and
> parsing. Just a couple small comments:
>
> On Oct 29, 2005, at 4:41 PM, Marco Gerards wrote:
>>
>> `if' accepts any command. I showed the example of using the `['
>> command. It can be made similar to the `[' command of coreutils.
>> This command sets the environment variable `RESULT' to either 0 or 1.
>> After execution `if' checks `RESULT' and either executes the `if' or
>> the `else' branch. It would also be possible to use a return value
>> instead of `RESULT', but that was too much trouble for me at first.
>> But of course this can be changed if someone can convince me of that.
>
> You want it to be "$RESULT" instead of "$?" ?
You are right.
> I really don't like that each command has to explicitly set RESULT. As
> you note, it would be better if the return code from the command were
> automatically placed into the status environment variable.
Most command return grub_err_t. The only commands that matter for us
are commands like `['. Would you propose every commands returns an
int and that on function return grub_errno is checked?
>> +#ifdef GRUB_UTIL
>> +void
>> +grub_lsb_init (void)
>> +{
>> + grub_register_command ("[", grub_cmd_lsb, GRUB_COMMAND_FLAG_CMDLINE,
>> + "[ EXPRESSION ]", "Evaluate an expression", 0);
>> +}
>> +
>> +void
>> +grub_lsb_fini (void)
>> +{
>> + grub_unregister_command ("[");
>> +}
>> +#else /* ! GRUB_UTIL */
>> +GRUB_MOD_INIT
>> +{
>> + (void)mod; /* To stop warning. */
>> + grub_register_command ("[", grub_cmd_lsb, GRUB_COMMAND_FLAG_CMDLINE,
>> + "[ EXPRESSION ]", "Evaluate an expression", 0);
>> +}
>> +
>> +GRUB_MOD_FINI
>> +{
>> + grub_unregister_command ("[");
>> +}
>> +#endif /* ! GRUB_UTIL */
>
> We *really* need to redefine GRUB_MOD_INIT/FINI to remove all this
> duplicated code. I guess I will add that to my list.
Cool :-)
>> +/* A part of an argument. */
>> +struct grub_script_arg
>> +{
>> + /* If this is 0, STR is a string. If it is one, STR is a variable
>> + name. */
>> + int type;
>
> This should probably be an enum.
Yes, good catch.
> Since this code won't break any existing behavior (simple "ls (hd,0)/"
> will still work, right?), I guess it can be committed as soon as
> serious issues like the memory leak have been fixed.
That is right. All normal code will continue to function, otherwise
it would be a bug or have been discussed on the list. So far there is
nothing that would break the current behavior except multiple lines
(which I should fix before committing).
--
Marco
next prev parent reply other threads:[~2005-10-30 21:04 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-29 21:41 Scripting support (PATCH) Marco Gerards
2005-10-30 5:25 ` Yoshinori K. Okuji
2005-10-30 9:45 ` Marco Gerards
2005-10-30 11:55 ` Yoshinori K. Okuji
2005-10-30 12:17 ` Marco Gerards
2005-10-30 10:14 ` Marco Gerards
2005-10-30 14:41 ` Vladimir Serbinenko
2005-10-30 16:05 ` Marco Gerards
2005-10-30 16:46 ` Vladimir Serbinenko
2005-10-30 16:59 ` Marco Gerards
2005-10-30 17:15 ` Vladimir Serbinenko
2005-10-30 18:17 ` Marco Gerards
2005-10-31 6:39 ` Yoshinori K. Okuji
2005-10-30 20:49 ` Hollis Blanchard
2005-10-30 21:04 ` Marco Gerards [this message]
2005-10-31 6:45 ` Yoshinori K. Okuji
2005-10-31 18:58 ` Marco Gerards
2005-11-01 19:06 ` Marco Gerards
2005-11-01 19:55 ` Yoshinori K. Okuji
2005-11-03 21:58 ` Marco Gerards
2005-11-06 22:26 ` Marco Gerards
2005-11-08 3:38 ` Hollis Blanchard
2005-11-08 18:24 ` Marco Gerards
2005-11-09 6:14 ` Hollis Blanchard
[not found] <200511010611.jA16B6Bq030884@dell01.dinaserver.com>
2005-11-02 9:37 ` adrian15
2005-11-06 22:13 ` Marco Gerards
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=871x22hg2x.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox