Ion Shell Development Discussion


In an attempt to spark some discussions within the Redox forums, I am creating a thread here specific to the development of the Ion shell, where general discussions may take place, and where I will update this thread over time as Ion development progresses and achieves more milestones.

Ion Shell Repository:
Ion Shell Manual:

Current Status

I have seen a lot of interest in the Ion shell over time as it has developed, and we are now on the verge of having a solid, stable system shell that can compete against the likes of Bash, Zsh, and Fish. At this time, there are only a handful of critical issues that need to be addressed before the Ion shell is ready for the greater world. As one might expect from a system shell project, these issues are mainly a few issues with job control not working as expected in a few areas, and a some parsing logic errors that are likely easy fixes. I’ve been busy with a lot of other projects so I haven’t gotten around to addressing the aforementioned issues, but if no one steps up to solve the problems I will likely be looking into them soon.

Contributors Welcome

Those interested in system shell development may drop on by the repository and scan through issues that have been reported and tagged on the Issues board.

If you require step-by-step direction and mentorship in solving the problem, even if you have no prior Rust experience, I am generally available to help, so you may reach out to me. Suggestions are also welcome, and discussions on existing issues are encouraged.


I really would like to start helping out with this. Right now, I don’t have the cycles, but, I hope to have some time in the coming weeks. I’ll definitely try tackling some of the issues you have tagged as soon as I can get some time. Thanks for organizing things nicely like this. Also, Kudos on the Rust-Gtk docs. They are awesome!


@mmstick, is it possible to replace BASH with Ion in something like Arch/Antergos and still use pacman etc.? I love being a guinea pig, and I like the noble stability Rust tries to provide.


I’ve been using Ion for most of the year on my systems. It will work perfectly fine for daily usage. You may also write some scripts with Ion, but you may run into a few snags until a few simple logic errors are addressed.

Mainly, we need to get arrays to optionally expand to no arguments, while allowing strings to be empty; and there seems to be a job control issue with some fd’s not getting closed when they should be closed (we have to interface directly with *nix file descriptors to perform forking and redirection efficiently). I’d also like to get some fuzzing in the mix to stress test all of the Ion shell’s code paths to find all the logic errors that may be hidden here and there down the line.

I’ve been busy writing a Rust GTK tutorial series though, so I haven’t seriously investigated these issues yet.


Oh my god @mmstick where was that tutorial when I needed it? I had to (painfully) ask some of the dumbest questions for both Gtk and Cairo.

For example, turns out Cairo won’t do write_to_png() or whatever until you have a variable that uses a function in the Rust stdlib that creates a file, then you have to pass that variable to the write_to_png() function…in C, it just wants a string and nothing more and nothing less.


Apropos of nothing, here’s a python script I wrote to print a bunch of pretty ion colors and their corresponding hex codes.

# save as; use:
#     ion -c "$(python3"
count = 0

while count < 0xFF:
    s = "${{c::0x{:02x},bold}} Hex value: 0x{:02x} ${{c::reset}}".format(count, count)
    count += 1
    print("echo ", s)

Save as and execute ion -c "$(python3".


Initially I tried to script this in ion, but it was hard for me to generate the appropriate escape sequences escaped within the language itself. Maybe there is a way.

In any case, I like customizing my prompt! Eventually we can use plugins for the prompt and syntax extensions. FWIW, I’m interested in developments in that area. I have always liked the idea of script layers calling into compiled libraries. Think Lua or Tcl. If ion could provide an easy way to (safely) load plugins, that’s powerful.


Try this out

for key in {0...9,a...f}{0...9,a...f}{0...9,a...f}
    eval echo -n \$\{c::0x$key\}0x$key,\' \'

Or go for the full 24-bit space:

for key in {0...9,a...f}{0...9,a...f}{0...9,a...f}{0...9,a...f}{0...9,a...f}{0...9,a...f}
    eval echo -n \$\{c::0x$key\}0x$key,\' \'

No Python needed then


As for plugin support, we actually already have support for string and string namespace plugins. There’s an existing git plugin that you can take advantage of.


@mmstick I’ve searched through the ion repo and googled. Where is the git plugin?


It’s referenced towards the bottom of the repository’s, next to the vim syntax highlighting plugin.


What is the opinion of everyone here on lambdas?


When referring to lambdas/closures, what specifically do you mean?


What level of support are they to be given.


The elvish shell uses them extensively, bash doesn’t like them at all, on what side of the debate is the ion shell?


Anonymous functions are not yet supported by Ion. We have yet to come up with a good syntax for the feature, if we even want the feature at all. It is possible to pipe the output of a named function to the input of another named function though. And you can replicate using functions as type parameters to other functions through a combination of the eval command and passing the name of the function.


To give an example of how you can use named functions in pipes:

fn add x y
    echo $((x + y))

fn and_add y
    read $x
    echo $((x + y))

add 3 5 | and_add 2


Ahh, thanks. What about the fsharp syntax of fun parameter1 parameter2 -> expression?


Another suggestion, to make this compatible for use with the type parser, is a syntax like so:

$[x y => expression(s)]
@[x:int y[] => expression(s)]

But we’d need some serious discussion and investigation of pros and cons before proceeding with anything.


Am wondering if this would be a good idea:

fn add x y
    echo $((x + y))

add 2 3 | add 3

Taking some inspiration from the D programming language, 2 and 3 from the first invocation would be x and y respectively; whereas in the second invocation, x would be read from stdin directly, and y would be assigned 3. Parsing rules would depend on the specified type parameters. So, for example, the following could be valid:

fn add x:int y:int
    echo $((x + y))

echo "1 4" | add

Any thoughts?


I like how clean this is to support composition. Also, I think it fits in with how shells work really well.