This page is for brainstorming a scripting language for gPXE.  Feel free to edit to your heart's delight - everything should be versioned by the wiki anyway!

=== Commands ===
The current gPXE shell strips whitespace from a line and splits into an ''argv[]'' array:
<code>
command [arg1 [arg2 [arg3 ...]]]
</code>

=== Variables ===
Currently, settings like the IP address and boot filename are available as variables.  In the future, scripts should be able to create temporary variables as scratch space.
<code>
set net0/ip 192.168.0.1
set my_ip 10.0.0.15
show net0/netmask
clear net0/gateway
</code>

Variable expansion is already available in mainline gPXE:
<code>
dhcp ${my_iface}
initrd http://etherboot.org/initrds/${node_id}.bz2
</code>

"References" could work like this:
<code>
set ref_to_ip net0/ip
show ${ref_to_ip}
=> ...value of net0/ip...
</code>

=== Arithmetic ===
Standard arithmetic operators should work for integral types:
<code>
set i ${(i / 2 + 1) * 2}
</code>

The operators are: ''+'', ''-'', ''*'', ''/'', ''%'', ''('', and '')''.

=== String manipulation ===
The format string built-in function allows string concatentation and formatting:
<code>
set net0/ip ${fmt("%d.%d.%d.%d", 192, 168, 0, 10 + host_num)}
</code>

=== Comparison and logic ===
The standard operators for integral and string types (string ordering probably isn't necessary though):
<code>
== != < > <= >=
</code>

They should either evaluate to special boolean values "true"/"false", or we need to define truth rules for all types (e.g. integral types are true if not equal to zero).

=== Control flow ===
The only control flow statement is the ''if'' statement:
<code>
if <expression> goto <label>
</code>

For example:
<code>
set i 0
loop:
    dhcp net${i}
    kernel ${kernel_url}
    boot
    set i ${i + 1}
    if ${i < $iface_count} goto loop
</code>

=== Needs discussion ===
  * We probably need an exit code built-in variable like ''$?'' in POSIX shell.
  * Bitwise operators ''|'', ''&'', ''^'', ''~'', ''<<'', and ''>>'' may be needed.
  * Focus needs to be on what we can leave out rather than what to add.
  * More use cases so we know what users need.

=== Links ===
  * [[http://bellard.org/otcc/|Obfuscated Tiny C Compiler]]
  * [[http://www.nicholson.com/rhn/files/dds_basic.c|TINY obfuscated C BASIC interpreter]]
  * [[http://www.ittybittycomputers.com/IttyBitty/TinyBasic/TinyBasic.c|TinyBasic]]
  * [[http://www.personal.leeds.ac.uk/~bgy1mm/Minibasic/basic.c|Mini BASIC]]