JoshMcguigan

It is not possible for a shell to know how to perform completions for every binary on a users machine. Shell completion scripts define the auto-completion for each specific binary, so for autocomplete to work (well) it needs to be supported both by the shell and by the application. This post is about writing shell completion scripts (the application side, not the shell side).

Author here. This blog post is the result of my puzzling over how auto-complete works in the shell, and subsequently whether shell completion scripts could be written in Rust. It also introduces a new Rust crate, shell_completion[0], which is a library that exposes some low level primitives for writing shell completion scripts in Rust. shell_completion is certainly in its infancy, so I'd be happy to have contributors of any kind (both code and opinions are welcome).

[0]: https://github.com/joshmcguigan/shell_completion

You can listen to the DHCP traffic caused by the button press (the button is sleeping until pressed, so every press causes DHCP traffic) and use that to trigger any action you'd like. I wrote a simple utility[0] to do just that.

The longer term issue, since these are being discontinued, is getting your wifi credentials into the dash button. At the moment I use the amazon app to do that, but I'd guess they'll be removing that functionality. I recall reading someone reverse engineering that process, but I'm not sure what came of it.

[0]: https://github.com/joshmcguigan/dashr

There is work being done now to improve this situation for clippy.

https://github.com/rust-lang/rust-clippy/issues/2604

As I was thinking about an improved user interface for the shell, it seemed like at some point you'd hit the limit of what is reasonable given the current split implementation between terminal emulator and shell. Do you think you'll get to a point where you'll need to build an all-in-one solution?

Thanks for sharing, your posts are very well written.

I really like the idea of syntax highlighting before the user presses enter.

Any reason you are writing your own posix parser and readline implementation, rather than using existing Rust crates?

I'm not confident enough to say this for sure, but I think you are off base.

I created a demo in the Rust playground [0] which shows that there is no implicit environment variable expansion. Also, the source for `std::process:Command` [1] looks to be calling into libc to perform a fork/exec.

That said, this is rather new territory for me, so let me know if I'm missing something here.

[0] : https://play.rust-lang.org/?version=stable&mode=debug&editio... [1] : https://github.com/rust-lang/rust/blob/master/src/libstd/sys...

I'd second the recommendation for rustyline. I played around with it a bit while reviewing the rush[0] project, another shell implemented in Rust for learning purposes.

[0]: https://github.com/psinghal20/rush

I've linked my GitHub profile below. I really enjoy social coding, so feel free to open pull requests or issues on any of my repos.

https://github.com/JoshMcguigan

Hi all, author here. I'm not sure of the rules around self promotion so I want to point out that I didn't submit this, but I'm happy to see that others are enjoying it.

I wrote this blog post to document my process of building a simple shell using Rust. I learned a lot about how shells, terminal emulators, and the OS interact by going through this exercise, so I hope this is useful to others as well.

Feel free to reach out if you have any questions.

Hi all, author here. I'm a long time hackernews lurker but I registered today when I saw traffic to a recent blog post I wrote coming from here.

I wrote this blog post to document my process of building a simple shell using Rust. I learned a lot about how shells, terminal emulators, and the OS interact by going through this exercise, so I hope this is useful to others as well.

Feel free to reach out if you have any questions.