No subject

based on conditions.  In my organization, I have gPXE hacks to enable
error-catching.  Boot.Kernel.Org and NetBoot.Me both employ custom gPXE
hacks to enhance their script capabilities.

So we've already had some discussion about the subject and I'm wondering
how to turn that discussion into action.  I would assume that the best
way to do that is to get consensus, since a forward-thinking change is
less likely to need reversal.

My personal opinion is that at a minimum, gPXE scripts should:
- Have the ability to continue in spite of individual command errors
- Have the ability to execute commands based on conditions

If we agree on syntax, semantics and behaviour, I would hope that
implementation is not too large a concern...  It could be that a
talented individual takes our scripting system and re-implements it
entirely, resulting in much less of a code cost.  But in the meanwhile,
we could put the capabilities out there to be enjoyed.

Stefan and I have been tackling some minor scripting additions.  For
some of these, it would be great to get agreement on whether or not they
belong in gPXE's scripting system.

'exit' : Allows you to early-exit a script and return to the calling
script.  This allows you to _prevent_ running later commands in the
current script.

'if <condition> <command>' : Stefan's fine implementation will execute
<command> is <condition> is a non-zero unsigned integer.  Although its
behaviour can already be mimicked somewhat with some of the ugliest
recursive-variable-expansion business you've ever seen in a gPXE script,
users might be more familiar with 'if' from other scripting/programming
languages.

': <label>' : This defines a "point-of-interest" in a script for jumping
to with 'goto'.  Regardless of implementation, can we agree on this
form/format?

Stefan and I worked through some examples of implementing loops and an
if-else construct where we realized that a "deferred execution" of
"routine bodies" headed by ':' was not as usable as the case where
"where they appear, there shall they be executed."  I had an idea that
we might gain a reduced code-size cost with the constraint that one can
only 'goto' a "routine" which has already been passed by the parser.  To
do this, I tried "deferred execution" of such routines.  This proved
difficult to express an if-else construct with.  A recent patch I've
submitted does not have this constraint and actually costs less code
than that strategy took anyway.

Another subject is the implementation of tracking these script label
points...  Stefan had the idea to search the script for the magic ":
<label>" sequence.  With this, you're guaranteed that jumping to a label
defined in your script will give meaningful behaviour.  An
implementation I have tried is storing the script offset in a generic
setting with <label> as its name.  A conflict might arise if a script
user tries to use the same label-name in more than one script or tries
to use actual setting names for label-names.

'goto <label>' : This simply jumps to a label in a script that is
defined by ':'.  Combine it with 'if' and you have branching.

Error-catching : I believe that Lynus implemented an ${rc} variable in
his scripting work for last GSoC.  Right now, any single command failure
will exit all executing scripts.

What does everyone think of the above?  If there were a vote, I'd vote
that 'exit' and 'if' are immediately useful while the other flow control
subjects are discussed.

Meanwhile in dream-land, it would be cool if there were low-level
primitives that one could use in a script to then further define the
scripting language itself.  Then users could pick their favourite
"flavour" and include it at the beginning of their script to determine
the behaviour of the rest of the script. :)

Thanks for your time,

- Shao Miller