1) I think you mean stuff like **/*.py from zsh, which bash now emulates with shopt -s globstar.
This has come up several times, and we should have it. But I'm actually not entirely sure how ** behaves -- if someone can write an exhaustive shell script that shows what it does (e.g. a bunch of mkdir and touch commands and output), we can copy it in our spec tests:
https://github.com/oilshell/oil/tree/master/spec
https://www.oilshell.org/release/0.17.0/test/spec.wwz/osh-py...
and then implement it. Generally once the behavior is spec'd out, it's not too hard to implement
2) Completion has a long history in the project -- we emulate bash completion very faithfully, but yeah I've realized that's not enough
This comment elaborates on a different plan -- I think something like "fishcomp" to emulate fish would be both useful and pretty feasible:
https://lobste.rs/s/fdqbhk/oils_0_17_0_ysh_is_becoming_real#...
We can definitely use help with that, and it's relatively self-contained.
3) What exactly do you mean by "programmable input" ? We support GNU readline so everything there should work (maybe the ./configure detection didn't find it for you?)
---
But there is a bigger reason for the "struggle" -- the main focus of the project now is YSH, the language with data tYpes, influenced by pYthon, JavaScript, Lisp, etc.
That is, a shell is both a language and an interactive UI, and I've long emphasized the language part, e.g. in the FAQ - http://www.oilshell.org/blog/2021/01/why-a-new-shell.html
The theory was/is that the language is not only important for the system level tasks, but also a good foundation for the UI, e.g. like Emacs is written in Emacs Lisp
So I think structured data (in the form of languages/protocols) in YSH is really the killer feature of Oils, that will hopefully bring many other people into the project, who can help with filling out the interactive features you mention, e.g. polishing completion.
I wrote FIVE posts about YSH in June: https://www.oilshell.org/blog/2023/06/release-0.16.0.html#so...
As mentioned in this post, the biggest risk is that we don't have enough help. All the technical pieces are there now, and the risks are about project management, not the code.
I appreciate everyone who contributed while the codebase was undergoing this big transformation to native code -- this was kind of risky and the most unusual part of the project, but I think it paid off!
(We also have big ideas for the interactive shell in the form of a headless protocol for GUIs, but again need help -- https://www.oilshell.org/blog/2023/06/release-0.16.0.html#he... )