While OSH aims to be strictly better than Bash, YSH aims to be strictly better than "shell written in Python[1]." If there is something shell-like that you think Python is superior to YSH for, then please give some examples before the language hits 1.0 so they can be taken into account.

1: Obviously a large general purpose program that only occasionally needs to run an external program is probably going to be better in Python due to the library ecosystem alone. I'm talking about those Python programs that use primarily some combination of pathlib, os, sys, and subprocess and exist only because of the deficiencies (perceived and real) of shell.

(author here) Funny thing is I also type out most of my shell into a script file. I generally don't create huge commands interactively. I elaborated on that here:

https://lobste.rs/s/pcuppu/what_helps_people_get_comfortable...

Basically I want to be able to use all the power of Unix without remembering it all -- shell is a great tool for that.

Someone made a LSP plugin for Oils awhile back, and I expect if enough people use it, those tools will arise. They will be MUCH easier to produce for Oils than shell, because we have a principled code representation. (Some tools will be inside the project, and some outside, as usual)

On the UI side, there are also people exploring shell GUIs via the "headless shell" -- something no other shell has -- but we can use more people to help.

screenshots: https://www.oilshell.org/blog/2023/06/release-0.16.0.html#he...

i.e. Join #shell-gui on Zulip; don't assume it will get done without your input or effort ... as mentioned in this blog post, the biggest risk is that we don't have enough people helping!

I can't contribute directly to open source because of my employer. But the pages you linked are very interesting. I may be interested in doing beta testing or something, so I'll join Zulip and say hi. Thanks!

Couldn't agree more and at this point, virtually every new mainstay tool I adopt is written in Zig or Rust and I can't see myself migrating to a shell written in C/C++. Especially when something like nushell so elegantly avoids the situation you're describing. (I use nushell as my daily driver shell, and bang out scripts in it on an hourly basis. It's a blessing to use, though still missing an essential "shell" feature or two)

There's only 7K lines of C++ in Oils, mentioned in this post, and we intentionally keep it down. (It's for the garbage collector and OS bindings -- basically the unsafe parts.)

The rest is typed Python (with algebraic data types), which more common and simpler than Zig or Rust.

It's not as fast as Zig or Rust, but

1. The shell is the same speed when it's running external processes (and we do measure)

2. I believe it can be as fast as bash's hand-written C, even for code that doesn't do I/O (which isn't common but exists). We're perhaps ~50% the speed now, being "hilariously unoptimized".

This release mentions a big optimization, but the bigger point is that we have leverage via metaprogramming. We can do transformations on the entire interpreter (e.g. "boxless" transformation)

3. It means we only have 40K lines of Python, compared to 142K lines of C in bash. If you add YSH, we will only have around 50K lines, compared to probably 200K lines if you wrote it by hand

So the whole program is closer to an executable spec -- there is less room for bugs to hide.

It's easier to optimize 50K lines that is known to be correct (with thousands of tests), than 200K lines of code

---

Our binary is about 1.5 MB of executable code with no dependencies other than libc and (optional) GNU readline.

On the other hand, shells in Rust seem to have a big tree of dependencies and end up at 20 - 50 MB. It's not the size I'm concerned about so much as the stability

As mentioned before, our approach is unusual, but I think the "usual" approaches haven't worked well. That said, I think if someone wrote a compatible shell from scratch in Zig or Rust (with limited dependencies), that would be also be valuable contribution

---

Oils is also aimed at the system level, and is an "exterior" shell that uses processes and file descriptors. Comparison with PowerShell, Elvish, nushell here:

https://www.oilshell.org/blog/2023/06/ysh-design.html#survey...

i.e. "shell" is a bit overloaded, and in some sense those tools are "one level higher".

Is it still missing job control?

That's basically the biggest thing I'm missing. I think there's still a few FD redirection tricks that I use occasionally in zsh that are also missing (and are hard to hack in due to lack of job control).

BTW Oils has job control (thanks to contributor Melvin Walls), and it also has almost almost all bash redirects ... any zsh redirects can likely be added trivially!

> Also when you do that you get all the benefits of using your riced-out, LSP-enabled editor

https://github.com/bash-lsp/bash-language-server

https://github.com/koalaman/shellcheck

https://github.com/idank/explainshell

i agree with that. i almost never create scripts though, because i work on multiple computers at once, and copying and adapting commandline snippets is easier than scripts that don't necesarily work the same on every machine. so i like improvements in the interactive experience like fish mostly focuses on. but if i were to write a script i would not use fish either.

that said, a language that focuses on shell scripts could be a good idea because there is not much work done yet in that space

> your riced-out, LSP-enabled editor

It’s my belief that “riced out” has negative racial overtones, and isn’t an appropriate adjective to be using. Wikipedia has some history on this related term: https://en.wikipedia.org/wiki/Rice_burner

Been browsing tech forums for years and years and I’ve only ever heard “rice” used as a compliment to refer to software that’s really aesthetically pleasing. Didn’t mean to offend, had no idea it was even a term borrowed from car culture.

Elk shell is quite different from traditional shells. More like Python. https://elk.strct.net